HTTP 标头是附加在每个 HTTP 请求和响应上的键值对，用于携带有关请求本身的信息（与实际发送的内容相互独立），例如由谁发起请求、期望以何种格式接收数据，以及应如何处理这些数据。在 Feed 管理中，正是标头让 Feed 平台能够向 API 验证自身身份、声明其发送或期望的是 JSON 而不是 XML，并传递缓存或压缩指令，而这些信息都不会混入请求正文中的实际商品数据。
为什么它对 Feed 管理很重要
Feed 平台与渠道（Google Merchant Center、Meta Catalog、零售商自己的 ERP）之间的每一个自动化连接，都依赖标头正确发挥作用。携带无效或过期令牌的 Authorization 标头会导致格式完全正确的 Feed 提交直接失败；而缺失或错误的 Content-Type 标头可能导致渠道把 JSON 载荷误解为纯文本（反之亦然），在不知不觉中损坏上传内容。限流和重试逻辑也存在于标头中：许多 API 会返回 Retry-After 或 X-RateLimit-Remaining 等标头，告诉 Feed 平台在被限流之前还能发出多少请求。当需要将数万个 SKU 同步到一个限制每分钟请求数的渠道时，这一点尤为重要。排查失败的 Feed 同步时，往往要先检查标头，因为请求正文可能看起来完全正确，而某个标头却在悄无声息地导致请求被拒。
如何运作
标头以纯文本行的形式发送，位于 HTTP 请求或响应的顶部，与 URL 和正文相互独立。一个典型的 Feed API 请求可能包含 Authorization: Bearer <token> 以证明调用方身份，Content-Type: application/json 以声明所发送数据的格式，以及 Accept: application/json 以指定期望返回的格式。与直接显示在地址栏中的查询参数或其他 URL 参数不同，标头在 URL 中不可见，因此是存放身份验证令牌等敏感信息的合适位置，这些信息不应出现在浏览器历史记录或服务器日志中。有些标头由客户端或服务器自动设置（例如 Date 或 Content-Length），而另一些标头（尤其是身份验证和自定义跟踪标头）则由集成的构建者显式配置。
示例
<!-- Representative HTTP request headers sent when a feed platform
pushes a product update to a channel's API -->
<item>
<g:id>SKU-40217</g:id>
<title>Ceramic Plant Pot - 8 inch, Terracotta</title>
<g:price>18.50 USD</g:price>
<sync_request_headers>
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json
</sync_request_headers>
</item>上面的 sync_request_headers 块并不是真实的 Feed 属性，但它展示了每次通过 API 调用（而不是批量文件上传）将该商品数据推送到渠道时，随附的标头元数据。
相关概念
标头与同样随请求传递的查询参数和 URL 参数协同工作，但彼此独立，关键区别在于可见性：标头不出现在 URL 中，这就是身份验证令牌存放在标头中、而不是附加在链接上的原因。三者共同决定了渠道的 API 实际接收到的内容，其中任何一个出错，都是 Feed 同步悄然失败的最常见原因之一。
