用TextEncoder将XML字符串转为Uint8Array再调pako.gzip()压缩，设Content-Encoding: gzip和Content-Type: application/xml上传；优先选pako.gzip()而非deflate，避免服务端兼容问题。
XML字符串怎么用 pako.js 压缩成 gzip 格式
pako.js 默认的 pako.gzip() 接口接收的是 Uint8Array，不是字符串。直接传入 XML 字符串会报错或产生乱码——因为没做 UTF-8 编码转换。
必须先用 TextEncoder 把 XML 字符串转成 UTF-8 字节流，再喂给 pako.gzip()：
const xml = ``; const encoder = new TextEncoder(); const uint8Array = encoder.encode(xml); const compressed = pako.gzip(uint8Array); // 返回 Uint8Array - test
注意：pako.gzip() 输出仍是 Uint8Array，后续上传需转为 Blob 或 base64，不能直接当字符串发。
上传时 Content-Encoding 怎么配才被后端识别
服务端是否解压，取决于你是否在请求头中正确声明压缩格式。只压缩数据却不设头，后端大概率当成普通 XML 解析失败。
必须显式设置：
Content-Encoding: gzip-
Content-Type: application/xml（保持原始类型） -
Content-Length由 fetch / XMLHttpRequest 自动计算，不用手算
示例 fetch 调用：
const blob = new Blob([compressed], { type: 'application/gzip' });
fetch('/api/upload', {
method: 'POST',
headers: {
'Content-Encoding': 'gzip',
'Content-Type': 'application/xml'
},
body: blob
});
⚠️ 常见坑：有人误设 Content-Type: application/gzip，这会让后端以为你传的是 gzip 文件本身，而非“已压缩的 XML”。实际内容类型仍是 XML，只是编码方式变了。
pako.deflate() 和 pako.gzip() 选哪个
两者都可压缩，但协议兼容性不同：
-
pako.gzip()生成标准 gzip 格式（含魔数、头信息），Java/Python/Nginx 等服务端开箱支持 -
pako.deflate()生成原始 deflate 流（无头），Nginx 默认不识别，Spring Boot 需额外配server.compression.enabled=true且指定deflate，容易踩坑
除非后端明确要求 deflate，否则一律用 pako.gzip()。它多几字节头部，但省掉一堆协商和配置成本。
压缩后体积没变小？检查这三点
XML 压缩效果差，通常不是 pako 问题，而是数据本身或流程出错：
- XML 含大量重复标签名但内容极短（如
12），压缩率天然低；建议先 minify（删空格/换行），再压缩 - 忘了
TextEncoder，直接pako.gzip(xmlString)→ 实际压缩的是字符串对象内存地址，结果不可预测 - 上传前把
Uint8Array错误转成了 base64 再塞进 JSON body（如{data: b64}），等于二次编码，服务端收不到原始 gzip 流
验证是否真压缩：打印 xml.length 和 compressed.length 对比，10KB 以上 XML 通常能压到 30%–50%。
