原生<form>提交无法压缩payload是硬限制，因浏览器固化处理会忽略Content-Encoding头；必须改用fetch+URLSearchParams手动压缩（Safari不支持），含文件时只能服务端解压。
原生 <form> 提交无法压缩 payload，这是硬限制，不是配置问题。想压，必须换方式。
为什么 Content-Encoding: gzip 在原生 form 中无效
浏览器对 <form method="POST" enctype="application/x-www-form-urlencoded"> 或 multipart/form-data 的提交路径做了固化处理：它会忽略你手动设置的 Content-Encoding 请求头，强制按 enctype 规则序列化并发送原始字节。哪怕你在 <form> 上加 onsubmit 拦截、用 fetch 重发，只要调用了 form.submit()，就仍走这条不可控链路。
常见错误现象：curl -H "Content-Encoding: gzip" --data-urlencode "a=1" ... 能压，但前端用 form.submit() 发出的请求抓包一看，Content-Encoding 字段根本没出现在请求头里，payload 也全是明文。
- 根本原因：HTML 表单提交是“语义化提交”，不是“通用 HTTP 请求”
- 兼容性断层：旧 WebView、Electron 旧内核、IoT 设备浏览器甚至不解析
Content-Encoding头，更别说解压 - 后端若开启 Nginx
gzip on，只对响应体压缩，对请求体无影响
用 fetch + URLSearchParams 压纯键值数据
适用于登录、搜索、筛选等不含文件的场景。核心是绕过表单默认行为，手动构造请求体并启用压缩流（现代浏览器）。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 监听
form的submit事件，调用event.preventDefault() - 用
new URLSearchParams(formElement)获取编码后的字符串 - 用
TextEncoder.encode()转成Uint8Array，再套CompressionStream("gzip")（注意：Safari 目前不支持，需降级为不压缩或服务端预协商） -
fetch中显式设headers: { "Content-Encoding": "gzip", "Content-Type": "application/x-www-form-urlencoded" } - 后端必须能解 gzip，并且 Nginx / API 网关要允许带
Content-Encoding的 POST 请求（默认可能被拦截）
示例关键片段：
form.addEventListener("submit", async e => {
e.preventDefault();
const params = new URLSearchParams(form);
const encoder = new TextEncoder();
const compressed = await new Promise(resolve => {
const cs = new CompressionStream("gzip");
const writer = cs.writable.getWriter();
writer.write(encoder.encode(params.toString()));
writer.close();
cs.readable.pipeTo(new WritableStream({ write: resolve }));
});
await fetch("/api/collect", {
method: "POST",
headers: { "Content-Encoding": "gzip", "Content-Type": "application/x-www-form-urlencoded" },
body: compressed
});
});
含文件上传时只能靠后端合并压缩
FormData 不支持直接压缩——它内部是分块构造 multipart boundary 的二进制流，无法在前端整体 gzip。强行 zip 后传，服务端收到的是一个加密 blob，不是标准 multipart。
真实可行路径：
- 前端保持
enctype="multipart/form-data"，不做任何压缩操作 - 服务端接收后，用
busboy/multer解析出所有字段和文件 buffer - 将文本字段 JSON 序列化，小文件（
- 大文件单独存对象存储，只在结构化 payload 中存 URL 和校验码
- 注意：10 个 1KB 小文件用
multipart提交，协议头开销比单个 10KB 文件多出约 2–3KB，合并后再传更省带宽
结构化压缩比单次 gzip 更值得投入
采集系统真正的瓶颈往往不在传输带宽，而在字段冗余和解析成本。比如 user_full_name、device_operating_system_version 这类长 key，在万级并发下每字段多占 20 字节，就是 200MB 额外 payload。
更稳的优化点：
- 用短标识代替长字段名：
fn替full_name，osv替os_version - 嵌套结构打平或转 JSON 字符串：
<input name="rows_json" value='[{"id":1,"v":"a"},{"id":2,"v":"b"}]'/></li> <li>布尔/枚举值用数字编码：<code>status=1而非status=active - 避免多个同名
<input name="tag">，改用name="tags"+ JSON 数组
这些改动不需要浏览器支持新 API，所有终端都兼容，且后端解析逻辑更确定——比押注 CompressionStream 的兼容性靠谱得多。
