HTML原生form提交不支持payload压缩，因浏览器忽略手动设置的Content-Encoding；需用fetch+FormData或URLSearchParams手动构造请求并启用压缩，且须后端配合解压。
表单提交时 payload 为什么不能直接压缩？
HTML 原生 form 提交不支持对请求体（payload）做 Gzip 或 Brotli 压缩——浏览器会忽略你手动设置的 Content-Encoding: gzip，并强制按 enctype 指定格式发送原始字节。也就是说，无论你前端怎么“预压缩”，只要走原生 submit，最终发出去的仍是未压缩的 application/x-www-form-urlencoded 或 multipart/form-data。
想压缩 payload，必须绕过原生 form.submit()
真正可行的方式是用 fetch + FormData 或 URLSearchParams 手动构造请求，并启用压缩：
- 对纯键值数据：用
new URLSearchParams(formElement).toString()获取字符串，再用TextEncoder.encode()转为Uint8Array，最后调CompressionStream（需现代浏览器支持）或后端协商解压 - 含文件上传时：只能用
FormData，但FormData本身不支持压缩；此时需在服务端接收后解包、合并、再压缩入库，前端保持enctype="multipart/form-data" - 关键点：
fetch请求头中必须显式设Content-Encoding: gzip，且后端 Nginx / API 网关要配置接受并解压该头
高性能采集系统里，结构化压缩的实际取舍
真实场景中，“结构化压缩”往往不是压缩单次 payload，而是优化整体采集链路：
-
name属性别用长英文字段名（如user_profile_phone_number），改用短标识（up_ph），减少 base64 编码膨胀和传输体积 - 多行文本（
textarea）提前在前端做轻量去重/空格折叠（.replace(/\s+/g, ' ')），比全量压缩更稳定 - 数组类数据（如动态表格行）避免用
rows[0][col]这种嵌套 name，改用 JSON 字符串塞进隐藏字段：<input name="rows_json" value='[{"a":"x"},{"a":"y"}]'>，后端统一解析 - 注意：
multipart/form-data中每个 part 都有边界开销，10 个 1KB 小文件比 1 个 10KB 合并文件多出约 2–3KB 协议头 —— 采集系统应优先合并小文件再上传
容易被忽略的兼容性断层
所谓“高性能”常默认现代浏览器，但采集终端可能包含老旧 WebView、IoT 设备内置浏览器或 Electron 旧版内核。这些环境大概率不支持 CompressionStream、fetch 的 duplex: "half"，甚至无法正确解析 Content-Encoding。实际部署前，必须用真实终端抓包验证 payload 是否真被压缩、服务端是否成功解压——而不是只看 fetch 调用是否报错。
立即学习“前端免费学习笔记（深入）”；
