JSON 压缩能明显减少接口流量吗？

它能减少源文本中的空白，但实际网络体积通常还受 HTTP 压缩、TLS、网关和客户端实现影响。不要把它当作完整性能优化方案。

签名请求体前应该压缩吗？

取决于接口约定。若签名基于原始请求体字节，任何空白变化都可能导致签名不同，应严格按接口文档生成最终文本后再签名。

格式化版本更容易定位字段层级和数组元素；压缩版本适合传输或复制，不适合人工排查。

第一类是复制到只接受单行文本的地方，例如部分命令行示例、环境变量、控制台字段或文档表格。第二类是需要把示例贴进 issue、工单或注释中，紧凑文本更容易避免换行被目标系统改写。

第三类是传输体积敏感但仍由人工处理的片段。需要注意的是，真正的网络压缩通常由 HTTP gzip、br 或平台配置负责，JSON 压缩只减少源文本中的排版空白。

先保留原始格式化副本，再用格式化工具确认字段层级、数组位置和必要字段。确认语法与结构后，再生成压缩结果，并把压缩结果放入目标请求位置。

如果接口有签名或摘要规则，必须确认精确签名字节。压缩会改变空白，还可能把 9007199254740993 变为 9007199254740992、把 -0 变为 0，或让重复键只留最后值；应先生成最终 body，再按协议签名和复核。

API 请求体经常包含访问凭证、用户标识、内部 URL、邮箱、订单号或客户资料。压缩只改变空白，不会隐藏这些值；分享前应先删除或替换敏感字段。

当前 minifier handler 没有上传步骤，但页面脚本、浏览器扩展、剪贴板、设备和操作流程属于不同风险边界。生产 payload 应在可信隔离环境中处理。