JSON 校验失败与长 ID 变值：两个容易混淆的问题

先处理语法，再处理业务含义

标准 JSON 要求属性名和字符串使用双引号，不支持注释、单引号和最后一个成员后的逗号。true、false 和 null 是小写字面量。遇到校验失败时，先检查这些常见问题，再看嵌套括号是否配对。

能被解析不表示业务数据一定正确。例如字符串形式的金额、缺少必填字段或错误的状态码仍可能通过语法校验。本站负责语法解析和排版，不替代接口字段约束或 JSON Schema 验证。

长整数为什么可能被悄悄改写

JavaScript 的普通数字采用双精度浮点表示，安全整数上限为 9007199254740991。超过这个范围的整数可能在解析时舍入。数据库里的 64 位 ID 即使在 JSON 中看起来很正常，也可能因此变化。

本站格式化工具会在解析前检查整数范围，拒绝可能丢失精度的数据。建议在数据源中把订单号、雪花 ID 等标识符输出为字符串，而不要等到格式化后再加引号，因为这时原值可能已无法恢复。

格式化与压缩的适用场景

缩进适合人工阅读与定位嵌套关系，压缩为一行适合复制到只接受单行的输入框。两者都会重新序列化数据，可能规范化数字写法、转义字符和重复属性的表现。对于有签名或原始字节要求的数据，不应先格式化再验证签名。

重复属性名在不同系统里可能产生不同结果。本站会拒绝同一对象的重复键，要求先在源数据中明确保留哪一个值，避免格式化时丢弃内容。

编码不是加密

Base64 和 URL 编码只是数据表示方式，任何人都可以按规则解码。不要把经过 Base64 的 API 密钥当作已经安全保存；URL 查询参数也可能出现在访问日志中。处理含凭证的样本时，先替换为测试值。