为何HTTP/3传输时未发送content-length请求头？

这事儿主要和HTTP/3的传输特性以及浏览器的默认行为有关，具体原因有这几点：

• HTTP/3默认倾向分块传输：HTTP/3基于QUIC协议，和HTTP/2一样都是二进制帧结构，天生适配分块传输（Transfer-Encoding: chunked）。当浏览器用分块方式发送请求体时，不需要提前计算并声明总长度，自然不会发送Content-Length头——这俩头在HTTP规范里本来就是互斥的，同时出现会有优先级问题，所以浏览器二选一的时候会优先用分块。

• 请求体无法提前确定长度：很多场景下浏览器没法提前知道请求体的总大小，比如表单上传带文件、动态生成的请求内容，或者用Fetch API的ReadableStream流式发送数据时，只能用分块传输，也就不会带上Content-Length。

• HTTP/3规范的隐性引导：虽然HTTP/3规范没禁止Content-Length，但QUIC的多路复用和流式特性让分块传输更高效，浏览器实现时默认就走分块路线，除非你手动指定请求头或者用能提前确定长度的请求体（比如固定长度的字符串），才可能看到Content-Length。

举个例子，如果你用Fetch API发送一个固定长度的Buffer，并且手动设置Content-Length，这时候HTTP/3请求里就会出现这个头；但如果是普通的表单提交或者动态内容，浏览器自动用分块，就看不到它。

内容的提问来源于stack exchange，提问作者lonix