原生 form.submit() 无法压缩 payload，因浏览器强制按 enctype 发送原始字节，无视手动设置的 Content-Encoding；必须改用 fetch + URLSearchParams 或 FormData 配合显式压缩头及后端解压支持。
原生 form.submit() 为什么压不了 payload
浏览器会无视你给 form 手动加的 Content-Encoding: gzip，强制按 enctype 发原始字节。无论你用 TextEncoder 预压缩还是改 header，只要走 submit()，发出去的永远是未压缩的 application/x-www-form-urlencoded 或 multipart/form-data。
这不是 bug，是规范行为：HTML 表单提交不参与内容编码协商，只负责序列化和边界封装。
- 常见错误现象：
fetch能压、form.submit()死活压不动，抓包一看 payload size 没变 - 根本原因：表单提交流程绕过 Fetch API 的编码控制链路，不触发
CompressionStream或服务端解压逻辑 - 兼容性断层：Electron 旧内核、Android WebView 67 以下、IoT 设备浏览器全都不支持手动压缩路径
纯键值数据怎么压缩上传
用 URLSearchParams 构造字符串，再转为压缩字节流，配合 fetch 显式设头。
- 步骤：取
form元素 →new URLSearchParams(form).toString()→TextEncoder.encode()→new CompressionStream("gzip")（需现代浏览器）→fetch(..., { body: compressedReadableStream, headers: { "Content-Encoding": "gzip", "Content-Type": "application/x-www-form-urlencoded" } }) - 注意：
Content-Type仍用application/x-www-form-urlencoded，后端要能按此类型解析解压后的原始字符串 - 降级方案：若不支持
CompressionStream，可前端用pako压缩成Uint8Array，再new Blob([arr], {type: "application/gzip"})传，但后端必须识别并解压
带文件上传时怎么处理压缩
FormData 本身不可压缩——每个 part 有固定 boundary，压缩会破坏分隔结构，服务端无法 parse。
立即学习“前端免费学习笔记（深入）”；
- 真实可行做法：前端保持
enctype="multipart/form-data"，不压缩；后端接收后，对各 part 内容单独解包、合并、再压缩入库 - 性能陷阱：10 个 1KB 小文件上传，实际 payload 多出 2–3KB boundary 开销；应优先在前端合并为单个
Blob或File再传 - 字段名优化比压缩更有效：把
user_profile_full_name改成ufn，device_sensor_temperature_reading_celsius改成t，实测可减小 30%+ 字节数
后端必须配什么才能真解压
Nginx 或 API 网关必须显式开启 gzip / brotli 解压，并透传 Content-Encoding 到上游服务。
- Nginx 示例配置：
gzip on; gzip_proxied expired no-cache no-store private auth; gunzip on;+proxy_set_header Content-Encoding ""; # 清除防止循环压缩 - Node.js Express 需用
compression中间件，并设filter: () => true（默认只解压 text/* 类型） - 容易被忽略的点：PHP 的
file_get_contents('php://input')在 Nginx 启用gunzip后才能拿到解压后数据；否则读到的是 gzip 二进制乱码
结构化压缩不是堆技术，而是权衡：字段精简、小文件合并、前后端解压协同，缺一不可。抓包验证 payload 是否真被压缩，比任何 console.log 都管用。
