一句话定义：HTTP 管线化（Pipelining）是 HTTP/1.1 中的一种优化思路：客户端不等上一个响应回来，就沿着同一条连接把后续请求连续发出去，像流水线一样往前推。
原理：像一桌人一口气点完菜
打个饭店比方。一桌客人把十道菜名一次性报给服务员，服务员跑一趟厨房就够，不用来回跑十趟，省下的是“往返”的时间。这确实划算。
但厨房有条规定：必须按报菜顺序上菜。第一道是佛跳墙，要炖两小时；后面的拍黄瓜三分钟就拌好了，也只能在出菜口等着，端不出去。这就是队头阻塞（Head-of-Line Blocking，HOL Blocking）。
问题的关键在于：管线化只优化了“发”，没动“回”。HTTP/1.1 的响应里没有编号，客户端只能靠顺序把响应和请求对上号：第一个响应就归第一个请求。所以服务端必须严格按序回复，哪怕后面的活早就干完了。
为什么它没普及
一是中间环节不配合。代理、缓存服务器对管线化的处理行为不一致，容易出岔子；二是出错后的处理方式含糊，比如某个请求失败，连接该断还是该继续，规范没说死；三是有更省事的替代方案，浏览器对同一域名直接开几条（通常 6 条左右）并发连接，收益差不多还好实现。主流浏览器事实上都关掉了管线化，所以今天聊它，更多是在讲一段历史和一类思维陷阱。
和多路复用差在哪
| HTTP/1.1 一问一答 | HTTP/1.1 管线化 | HTTP/2 多路复用 | |
|---|---|---|---|
| 请求发送 | 等响应再发下一个 | 连发不等 | 连发不等 |
| 响应顺序 | 天然有序 | 必须严格按请求顺序 | 任意顺序，靠流 ID 归位 |
| 应用层队头阻塞 | 有 | 有，且更明显 | 基本消除 |
| 传输层队头阻塞 | 有 | 有 | TCP 层仍然有 |
多路复用（Multiplexing）的做法，是把每条消息切成带编号的小帧（frame），交错着发，接收端按编号重新组装。它改的是协议本身：给消息加了编号，“回”这一侧才真正松绑。管线化只是在旧规则上强行提速，规则本身没变。
对实际工作的意义
第一，别把“并发”和“管线化”混为一谈。批量调用模型接口跑任务时，真正管用的是连接池、受控的并发数和服务端限流，而不是在同一条连接里强行塞入请求；有依赖关系的调用链本来就无法并行。
第二，队头阻塞是分层的。HTTP/2 消掉了应用层那一层，但一个 TCP 连接丢个包，所有流仍得等它重传；这正是 HTTP/3 改用 QUIC 的动机之一。排查“接口不慢但整体很慢”时，先想清楚卡在哪一层。
具体的协议支持情况与参数配置，以官方文档为准。