Nginx默认对静态资源不启用Chunked，因其能直接获取文件大小并设置Content-Length，而HTTP/1.1规定二者互斥；仅当gzip压缩后长度未知、使用sub_filter、代理回传Chunked响应或Lua流式输出等特殊场景才会回退使用。
Nginx 默认对静态资源不启用分块传输编码（Chunked Transfer Encoding），除非明确触发或满足特定条件。它在静态资源缓存场景中，本质上是“回避”而非“依赖” Chunked；真正起作用的是缓存控制头、sendfile 机制和文件分片（Range）支持。
为什么静态资源通常不用 Chunked？
Nginx 处理静态文件（如 .js、.css、.png）时，只要知道文件大小（Content-Length 可确定），就会直接发送完整响应，并带上 Content-Length 响应头。此时 HTTP/1.1 协议规定：有 Content-Length 就不使用 Chunked —— 这是标准行为，不是 Nginx 的限制。
只有当以下情况出现时，Nginx 才可能回退到 Chunked：
- 启用了 gzip on 且压缩后长度未知（例如动态压缩未预计算）
- 使用了 sub_filter 或其他输出过滤模块，导致响应体被流式修改
- 代理后端返回了 Chunked 响应，且未配置 proxy_buffering off 或未强制关闭 transfer-encoding
- 响应体由 Lua 脚本生成、无固定长度（如 ngx.say() 流式输出）
缓存与 Chunked 的兼容性问题
Nginx 的 proxy_cache 和 fastcgi_cache 默认不缓存 Chunked 响应。原因很实际：
- Chunked 是传输层编码，不是内容本身；缓存需存储原始有效载荷，而解码 Chunked 需完整接收并重组，增加开销
- 缓存元数据（如 key、headers）依赖 Content-Length、ETag、Last-Modified 等字段，Chunked 响应往往缺失或不可靠
- 若后端返回 Chunked + 200，Nginx 缓存时会尝试去除 transfer-encoding 并补上 Content-Length —— 但仅当能准确计算出长度时才成功；否则缓存失败或降级为不缓存
因此，如果你发现缓存命中率低、X-Cache-Status 总是 MISS，检查后端是否无意返回了 Chunked 响应（尤其 Spring Boot、某些 Node.js 框架默认启用 streaming）。
如何确保静态资源缓存稳定？
核心是让 Nginx 获得确定的长度和可缓存的响应头：
-
禁用不必要的 Chunked 输出：后端服务显式设置
Content-Length，关闭 streaming response - 静态文件走本地 root + expires：直接由 Nginx 读取磁盘文件，天然带 Content-Length，完全绕过 Chunked
- 代理静态资源时开启 proxy_buffering（默认 on）：强制 Nginx 完整接收后端响应再转发，从而有机会计算长度、移除 transfer-encoding
-
加一层校验头：在 server 块中添加
add_header X-Content-Length $sent_http_content_length;，便于排查是否丢失长度
补充：Range 分片 ≠ Chunked
容易混淆的一点：Nginx 支持 Range 请求（如视频拖动、大文件断点续传），返回 206 Partial Content 并带 Content-Range 头——这和 Chunked 无关。它依然返回确定长度的片段，响应头含 Content-Length，完全可被客户端或 CDN 缓存。Chunked 是传输编码方式；Range 是内容协商机制。
