不传Header接口不认你：零基础AI编程第20课详解HTTP请求头

调用 API 接口不仅仅是把数据发过去就完事。服务器在处理请求时，还需要明确知道三件事：你是谁？你发送的是什么格式？你从哪里来？这三项关键信息都依赖于 HTTP 请求头（Header）来传递。

Header 的本质：快递单与包裹

为了形象地理解 Header 的作用，我们可以将其比作快递物流中的“寄件单”。

• Body（正文）：相当于包裹里的实际物品，即你发送的具体数据。
• Header（请求头）：相当于贴在包裹外面的快递单。

如果没有这张“快递单”，快递员（服务器）就不知道包裹是谁寄的、应该如何处理。因此，Header 是服务器正确解析和处理请求的前提。

最常见的三类 Header

在实际开发中，Header 主要承载以下三类核心信息：

1. 身份信息：Authorization

这是用于验证用户身份的凭证。通常在用户登录后，服务器会返回一个 Token。在后续的每次请求中，都需要将这个 Token 放在 Header 中。

• 标准写法：Authorization: Bearer <你的Token>
• 作用：服务器通过识别该字段，确认请求者已登录并拥有相应权限。
• 后果：如果未携带此 Header 或 Token 无效，服务器通常会直接返回 401 Unauthorized 错误，拒绝访问。

2. 格式声明：Content-Type

该字段用于告诉服务器你发送的数据格式是什么。

• 常见值：application/json（JSON 格式）、application/x-www-form-urlencoded（表单格式）、multipart/form-data（文件上传）等。
• 作用：指导服务器如何解析 Body 中的数据。
• 后果：如果格式声明与实际数据不符，或者服务器不支持该格式，会导致解析失败。此时数据虽然发送过去了，但服务器“看不懂”，通常会返回 415 Unsupported Media Type 错误。

3. 来源信息：Origin

浏览器在发起跨域请求时，会自动带上 Origin 字段。

• 作用：告知服务器请求是从哪个地址（域名）发出的。
• 应用场景：服务器利用 CORS（跨域资源共享）机制，根据 Origin 判断是否允许该请求放行。

调试建议：遇到报错先查 Header

很多开发者在调用接口不通时，往往第一时间检查 URL 地址是否正确，而忽略了 Header 的配置。事实上，大部分接口调用失败并非地址错误，而是以下两个原因：

1. Token 未携带或格式错误：导致身份验证失败。
2. Content-Type 写错：导致数据解析失败。

排查技巧： 下次遇到 401（未授权）或 415（不支持的媒体类型）报错时，请优先检查 Header 中的 Authorization 和 Content-Type 字段是否正确配置。

你知道 Header 里最常放什么吗？欢迎在评论区分享你的经验。