审查之前先格式化并检视 JSON

压缩过的 JSON 是为机器准备的：一行到底、没有缩进、键的顺序由序列化器随手产生。让眼睛去审查那堵墙，被移除的权限、被翻转的开关、多出来的端点就会这样溜过去。

美化打印也是你手边最便宜的合法性检查：一份解析失败的文档在生产环境同样不会正常工作，在审查标签页里发现这一点，远好过在部署日志里发现。

• 只改可读性格式化是可读性变换：它只改变空白与换行，从不改变数据，因此格式化副本总是可以安全地与原文件对照审查。
• 深度即信号一致的缩进让嵌套深度一目了然，而深度正是配置错误的藏身之处——放深一层的选项会被直接忽略。
• 交付期望的形态审查格式化副本，但交付系统期望的形态；美化打印是给人看的，不是给传输用的。

树状视图直接回答审查者真正关心的问题——有哪些键、每个值是什么类型、结构有多深——而不必数括号。原始文本一个问题也答不快。

JSON Tree Viewer 显式解析：按下“解析 JSON”之前什么也不渲染；非法输入会得到带位置的错误和修复提示，而不是静默失败。结果以可展开的树呈现，逐节点显示类型与数量，“Formatted”标签页则按你选择的缩进展示规范化文档。

解析摘要报告节点数与最大深度，可快速对照负载应有的规模。保留的原型键会被拒绝，因此恶意负载无法在你检视时伪装成无害数据。

树还让审查对话更具体：“items 的第三个元素 price 为 null”是任何人都能秒级验证的评论，而压缩行里的字节偏移不是。

一旦键的顺序变化，用眼睛对比两份 JSON 就会失效。结构化 diff 解析两侧，报告真正变化的部分——新增、删除与修改的值——与顺序和空白无关。

Text & JSON Diff 提供三种模式：行、字符与 JSON。JSON 模式是审查用的确定性模式：两份文档先被解析，再逐值比较，因此重排的键与重排的空白会正确地报告为完全相同。

对于非 JSON 文本，行与字符模式带有忽略空白和换行符归一化开关，摘要会计数新增、删除与修改。负载与配置用 JSON 模式；当一侧根本不是合法 JSON 时，退回行模式。

确定性的意义不止于方便：两位审查者运行同一比较必须得到同一答案，否则审查就变成了关于工具的扯皮，而不是关于变更的决策。

这些是带有明确上限的本地运行时，规模面向审查负载，而不是批量数据处理。知道上限，就知道什么时候该改用桌面工具。

上限之所以存在，是因为解析与 diff 就在你正在阅读的同一个标签页里运行；诚实的上限好过卡死的页面，而且工作区会把超限报告为明确错误，而不是静默截断。

• 查看器上限JSON Tree Viewer 接受最大 256 KiB 输入、40 层嵌套与 10,000 个节点——应付 API 响应或配置文件绰绰有余。
• Diff 上限Text & JSON Diff 每侧最多比较 256 KiB，最多报告 10,000 条差异记录，超出即声明比较过于复杂。
• 超出浏览器更大的导出——数据库转储、日志归档、生成的夹具——属于桌面编辑器或命令行工具，而不是浏览器标签页。

一个能在大多数负载问题进入生产之前拦下它们的简短流程。

对生产方的样例数据和真实负载都跑一遍清单；与现实不符的夹具和 bug 一样会让审查失效。

• 解析先格式化并解析：确认文档合法，并扫一眼节点数与深度是否符合预期。
• 检视检视树：检查叶子处的类型——数字标识符以字符串形式到达，是经典的集成 bug。
• Diff用 JSON 模式与上一个已知良好版本 diff，逐条读完所有报告的变化再批准。

审查负载常常包含客户记录、令牌或内部 URL。本地查看器把这些材料留在标签页里：文本由运行在你设备上的代码解析，整个操作过程中不参与任何网络传输。

正是这条边界，让这些工具可以在审查中处理真实的预发布负载。它并不免除你自己的责任：导出的文件、剪贴板内容与树的屏幕截图，一旦离开工作区仍由你谨慎处理。

如果必须在审查中分享负载片段，只粘贴能说明问题的最小摘录，并先隐去标识符——与支持渠道要求的纪律相同。