JSON压缩应优先结构优化再协议压缩：用JSON.stringify(obj,null,0)去空格、缩键名、删冗余；稳定结构可用MessagePack/CBOR二进制替代；HTTP层启用gzip/Brotli最省心；仅离线等特殊场景才手动压缩。
JavaScript 中 JSON 字符串压缩不是靠“给 JSON 加个压缩函数”实现的，而是分层处理：优先精简内容本身，再借助协议层或专用库做进一步压缩。直接对 JSON.stringify(obj) 的结果调用 gzip 是低效且不推荐的常规做法——浏览器和服务器早就在帮你做了。
先从源头减体积：结构级优化
这是最有效、零成本、无兼容性风险的方式。JSON 体积大，往往因为人写得“太友好”：
-
去掉空格换行：用
JSON.stringify(obj, null, 0)生成紧凑单行格式，比带缩进的版本小 20–40% -
缩短键名：
{"user_name":"Alice","created_at":1723582200}→{"un":"Alice","ca":1723582200}。需配套维护字段映射表，适合固定结构高频接口 -
避免冗余值：剔除
null、默认值字段；用数字代替布尔（"active":1）、整数代替带小数的金额（单位转为“分”） -
合并重复数据：如多个对象共用相同城市名，可提取为公共数组 + 索引引用：
{"cities":["Beijing","Shanghai"],"users":[{"city":0},{"city":1}]}
用二进制序列化替代 JSON 文本
当结构稳定、前后端可控时，换一种更紧凑的格式比死压 JSON 更高效：
-
MessagePack：语义等价于 JSON，但二进制编码，体积通常减少 30–50%。前端可用
msgpack5，后端 Node.js/Python/Java 均原生支持 - CBOR：RFC 8949 标准，支持更多类型（如 Date、Uint8Array），压缩率与 MessagePack 接近，调试友好（有文本表示）
-
注意：这类方案需前后端约定格式，不能直接被
fetch().json()解析，要改用对应解码器
协议层自动压缩（最常用、最省心）
现代浏览器发请求时默认带 Accept-Encoding: gzip, br；只要服务端启用 gzip 或 Brotli，整个响应体（含 JSON）就会被自动压缩传输，前端完全无感：
立即学习“Java免费学习笔记（深入）”；
- Nginx 配置示例：
gzip on; gzip_types application/json; - Express 配置示例：
app.use(compression({ brotli: true })); - 验证方式：看 Chrome DevTools Network 标签页中 Response Headers 是否含
Content-Encoding: gzip或br - 无需前端写任何压缩代码，
response.json()仍可照常调用
前端手动压缩（仅限特殊场景）
只有在无法依赖 HTTP 压缩时才考虑，比如离线 PWA 向自有后端发大包、或需存入 localStorage 超过 5MB 限制：
-
推荐 lz-string：专为 JS 设计，支持 UTF-16 / Base64 编码，兼容所有浏览器，API 极简：
LZString.compressToUTF16(str) -
需要二进制输出时用 pako：提供标准 gzip 实现，返回
Uint8Array，适合搭配fetch的ArrayBufferbody 发送 - 避坑提示：手动压缩增加 CPU 开销；压缩后数据无法被 CDN 缓存；Base64 编码会使体积膨胀 ~33%，慎用于 URL 参数
