什么时候要压缩JSON？
JSON 压缩（minify）解决的是「通道」而不是「阅读」：广告监测 SDK、短链跳转参数、老旧网关、甚至某些 IM 的代码块，对换行与总字节长度极其敏感，多一个换行符就可能截断。运营手里是漂亮多行 JSON，研发却要一行塞进 curl 或埋点字段；自己手工删空格极易误伤字符串里的合法空格。在线 JSON 一行化在保留语义的前提下去掉冗余空白，体积更接近 gzip 前的原始传输形态，也减少从 Word、邮件里复制时夹带不可见分隔符的概率。注意：压缩不会替你脱敏，token 仍在明文里；它只是让包更小、更不易被聊天软件自动换行拆碎。把「可读版」留在内部文档，把「紧凑版」交给对长度挑剔的系统，是成熟团队常用的双轨交付。
如何把多行 JSON 安全压成单行给埋点或网关使用
- 先对原始文本做语法校验，确认无尾逗号与注释；若含 `//` 说明段，请先删除或改成 `_comment` 字段，否则标准 JSON 解析会直接失败。
- 执行 JSON 压缩/最小化，观察输出长度与字符集：若需放进 URL query，应再整体做一次 URI 组件编码，而不是只压 JSON 本体。
- 在目标 SDK 或测试环境用小流量回放：重点看是否触发「参数过长」与是否被 CDN 缓存策略误伤；通过后把紧凑串写入配置中心，并在变更单附上压缩前后字符数对比。
JSON压缩常见问题
我把活动配置 JSON 压缩成一行后，对方系统仍提示非法，这通常是我的压缩坏了还是对方解析器更严格？
先拿压缩结果在本地 `JSON.parse` 与在线校验各跑一遍；若仍合法，多半是对方要求 application/json 头、或禁止某些 Unicode 未转义、或限制字段顺序。请让对方返回具体错误码与样例请求，而不是只说「不行」。
压缩会不会把长 URL 或带空格的活动名称里的空格删掉，从而导致链接失效或文案缺字？
合法 JSON 字符串内的空格属于值的一部分，压缩只删「引号外侧」的结构空白，不应删字符串内空格；若你发现值被截断，多半是复制时被聊天软件折行，请改用文件传输或对象存储链接。
我需要把压缩后的 JSON 再 Base64 一层塞进 header，顺序上应该先压再编还是先编再压才不容易踩坑？
应先得到严格合法 JSON 文本，再 minify，最后整体 Base64；若先 Base64 再压，会破坏 Base64 字母表结构。与网关同学对齐「payload 已是 UTF-8 JSON string 还是 bytes」也能避免双重编码。
埋点同学担心压缩让排查困难，线上又想保留可读性，有没有兼顾日志采样与线上体积的做法？
常见做法是线上发紧凑 JSON，同时在灰度环境保留美化版对照；或在日志里只打 hash 与关键标量字段，把完整 JSON 异步投递到受控观测平台。别指望压缩工具替你设计可观测性，需要产品与 SRE 一起定字段分级。
压缩后的单行非常长，我在企业微信里发送会折叠或截断，有没有不牺牲语义又能让同事收到的传输策略？
改用文件、代码片段云链接或内部 paste 服务传原串，在 IM 里只发校验和与行数；或在消息里拆成多条时务必标明「分段 1/3」并提示接收方用脚本拼接，否则极易拼错顺序。