Next.js默认不提供响应体压缩功能，需交由Nginx、CDN等边缘层处理；若自托管需在中间件中用stream.Transform接管socket并手动压缩，且仅针对text/*、application/json等MIME类型。
Next.js默认不开启Gzip/Brotli压缩，需手动配置中间件或反向代理
Next.js内置的next start服务器（基于Node.js原生http模块）**完全不提供响应体压缩功能**——无论你返回JSON、HTML还是流式文本，Content-Encoding头默认为空，浏览器收到的是原始未压缩字节。这不是遗漏，是设计取舍：Next.js把压缩交给更专业的边缘层或反向代理（如Nginx、Cloudflare、Vercel Edge）。直接在Node层做压缩会增加CPU开销、干扰流式响应，并与边缘缓存策略冲突。
用中间件强制启用Brotli/Gzip需绕过Next.js内置响应机制
如果你必须在本地或自托管环境启用压缩（比如调试阶段验证压缩效果），不能依赖res.end()或return Response——这些路径会跳过自定义压缩逻辑。唯一可行方式是使用stream.Transform包装原始res.socket，并在middleware.ts中拦截所有匹配路径：
- 只对
text/*、application/json、application/javascript等可压缩MIME类型生效，避开image/*、video/*等二进制类型 - 检查
req.headers['accept-encoding']是否含br或gzip，优先选Brotli（zlib.createBrotliCompress()） - 必须调用
res.socket?.write()而非res.write()，否则压缩流无法衔接到底层TCP连接 - 示例关键片段：
import { createBrotliCompress, createGzip } from 'zlib'; import { pipeline } from 'stream/promises'; export async function middleware(req: NextRequest, ev: NextFetchEvent) { const acceptEncoding = req.headers.get('accept-encoding') || ''; const isBr = acceptEncoding.includes('br'); const compress = isBr ? createBrotliCompress() : createGzip(); // ⚠️ 此处必须获取原始socket并接管写入 const socket = (req as any).socket; if (socket && !socket.destroyed) { pipeline(compress, socket).catch(() => {}); return new Response(null, { status: 101 }); // 升级协议，避免Next.js后续处理 } }
检查压缩是否生效：别信开发者工具的“Size”列
Chrome DevTools Network面板里显示的Size列是解压后体积，不是网络传输量。真正判断压缩是否起作用，看三点：
-
Response Headers里是否有Content-Encoding: br或gzip -
Content-Length头数值是否明显小于未压缩时（例如JSON从120KB降到35KB） - 用
curl -H "Accept-Encoding: br" -I https://yoursite.com/api/data直接查响应头，排除浏览器缓存干扰 - 如果用Vercel部署，
Content-Encoding由边缘自动添加，但Content-Length可能显示为chunked——这是正常现象，Vercel不透传压缩后长度
生产环境强烈建议交由Nginx或CDN处理压缩
自己在Node层做压缩会拖慢首字节时间（TTFB），尤其影响流式API（如SSE、ReadableStream返回）。Nginx配置只需两行：
gzip on; gzip_types application/json text/plain text/html application/javascript;
而Cloudflare默认开启Brotli，无需额外设置。重点在于：**不要在Next.js API路由里调用res.setHeader('Content-Encoding', ...)——这会导致客户端解码失败，因为Node层并未实际压缩响应体**。
