请求报文四部分：

POST /api/order HTTP/1.1              ← 请求行：方法 + 路径 + 协议版本
Host: api.example.com                 ← 请求头
Content-Type: application/json
Content-Length: 27
                                      ← 空行（关键分隔符）
{"id":123,"count":1}                  ← 请求体

响应报文四部分：

HTTP/1.1 200 OK                       ← 状态行：协议版本 + 状态码 + 原因短语
Content-Type: application/json        ← 响应头
Cache-Control: no-cache
                                      ← 空行
{"code":0,"data":{}}                  ← 响应体

那个空行为什么重要？

因为 HTTP 头部是变长的 —— 服务端读到一个空行才知道"头结束了，后面是 body"。这也是为什么头部字段不能包含裸的换行符，否则就能伪造出一个假的分隔，这类攻击叫 HTTP 响应拆分。

实际工作中会遇到的几个细节：

① 头部太大会被拒绝。 常见于 cookie 膨胀 —— 每个同域请求都会带上全域 cookie，塞多了轻松几 KB，超过网关限制就返回 431 或直接被断开。所以静态资源该放独立的无 cookie 域名。

② 自定义请求头有代价。 跨域时会触发 OPTIONS 预检，等于每个请求变两个往返；中间的 CDN/网关也可能不透传未知的头。能放 body 就别放头里。

③ Content-Length 和分块传输二选一。 知道总长度就用 Content-Length；流式响应（SSE、大文件、AI 逐字输出）用 Transfer-Encoding: chunked，此时没有总长度，所以做下载进度条时算不出百分比。

④ HTTP/2 之后报文结构变了。 起始行和头部被压缩成 HEADERS 帧（用 HPACK 编码），body 变成 DATA 帧，不再是纯文本。所以严格说"报文由文本行组成"只适用于 HTTP/1.x——但概念层面的四部分划分仍然成立。

五大类，看首位数字就知道谁的问题：

这个划分在排查时很实用：看到 4xx 先查自己的请求（参数、鉴权、方法），看到 5xx 直接找后端。

必须记住的这些：

三组最容易混的：

① 401 vs 403 —— 401 是"你是谁我不知道"（该跳登录），403 是"我知道你是谁但你不能干这个"（该提示无权限）。前端拦截器把两者混在一起处理，会导致越权用户被反复踢到登录页。

② 301 vs 302 —— 301 会被浏览器硬缓存，之后连请求都不发。临时跳转误用 301，活动结束后老用户依然被强制跳走且清不掉，只能换新路径。

③ 502 vs 504 —— 502 是上游返回了无效响应（服务挂了），504 是上游根本没在超时前返回（处理太慢）。区分开能直接告诉后端往哪个方向查。

一个工程上的强建议：不要用 200 + body 里的 code 表示业务失败。监控和网关只看 HTTP 状态码，全是 200 就发现不了故障；CDN 还可能把错误响应当成功缓存下来。正确做法是 HTTP 状态码反映请求本身的结果，业务细分错误码放 body。