JSON Formatter and Validator：API 调试流程
用 JSON Formatter and Validator 排查 API 响应和请求 payload，先区分 JSON 语法错误与业务 schema 问题，再检查转义、数字格式、嵌套结构、JWT 或 Base64 包装数据、Unicode 编码和生产数据脱敏边界，保留原始响应与最小复现样例。
API 响应出问题时，真正有价值的问题不是“怎么把 JSON 美化一下”，而是“这段文本是不是合法 JSON，结构是否能被读懂，payload 是否符合应用约定”。格式化让结构更清楚，校验确认语法是否成立，但两者都不能单独证明业务数据正确。
先区分语法问题和数据问题
使用 JSON Formatter 时，建议分两步。第一步，把文本当作 JSON 做语法校验；第二步，再用格式化结果查看字段、嵌套、数组和可疑值。把这两件事分开，可以避免一个常见误判：以为排版变漂亮就代表 payload 合法且 API 会接受。
JSON 语法比 JavaScript 对象字面量严格。对象 key 必须是双引号字符串；字符串也必须使用双引号，不能使用单引号；控制字符需要转义；数字不能写成 `NaN`、`Infinity` 或带尾随小数点；数组和对象最后一项后不能有 trailing comma。空白可以出现在 token 之间，但不能修复错误标点或错误引号。
应用数据还有自己的规则。一个 payload 语法完全合法，仍然可能因为 `id` 是字符串而不是数字、枚举值不在允许范围、缺少必填字段，或者嵌套对象出现在 schema 要求数组的位置而失败。因此 JSON 校验只是第一道门，不是最终结论。
先读第一个错误，不要整段乱改
校验失败时，先处理第一个报错位置。靠前位置缺一个逗号或引号，可能会引发后面一串连锁错误；修正第一个问题后，后续报错可能全部消失。检查报错行、上一行，以及最近的左花括号或左方括号。大多数 JSON 语法错误都很局部，但报错信息看起来复杂，因为解析器只能告诉你它在哪里卡住。
常见问题包括最后一个属性后多了逗号、从 JavaScript 示例里复制了单引号字符串、Windows 路径里的反斜杠没有转义、字符串内部直接粘贴了换行，以及从配置文件复制了注释。JSON 是数据格式，不是 JavaScript 代码；很多在代码里自然的写法，在 JSON 里是非法的。
调试时保留原始响应
不要在唯一一份失败响应上直接修改。先保存原始文本，再复制一份用于格式化。这对比对客户端日志、服务端日志、浏览器 Network 输出和客服工单很重要。整理后的样例更容易读，但原始响应才是证据。
API 调试建议保留三份内容：原始响应、格式化响应、最小复现样例。原始响应证明线上实际返回了什么；格式化响应方便人读；最小复现样例隔离触发错误的字段或嵌套结构，让其他开发者不用阅读完整 payload 也能复现问题。
只有确认包装格式时才解码
很多 payload 会把 JSON 放在另一层格式里。JWT 的 header 和 payload 是 Base64URL 编码的 JSON 片段，因此查看 token 结构时应使用 JWT Decoder，不要把整段 token 当普通 JSON 粘贴。某些 API 也会返回 Base64 包装的 JSON 字符串，这时可以先用 Base64 Encoder 解外层，再校验解码后的 JSON。
但不要猜测所有看不懂的字符串都是编码后的 JSON。如果解码结果像二进制、乱码或不是有效 UTF-8，它可能是加密、压缩、签名结果，或者根本不是 JSON。强行格式化只会制造误导。
有意识地处理转义和 Unicode
转义是 JSON 调试中最常见的坑。字符串里的反斜杠会开启转义序列。Windows 路径如 `C:\temp\file.json` 在 JSON 文本里需要转义反斜杠。字符串里的换行应表示为 `\n`，不能随意粘贴成真实换行，除非生产方正确序列化。
现代 Web API 通常应能处理 Unicode 文本，UTF-8 是互操作场景下的实际默认选择。问题常出现在系统重复转义、混用编码，或把已经序列化过的字符串再次序列化。格式化后如果看到异常的 `\u` 序列、破碎字符，或者整个对象外面多了一层引号，应优先检查生产方，而不是只手动修改最终文本。
脱敏时保持结构不变
在线工具很方便，但真实生产 payload 往往包含密钥、access token、客户记录、邮箱、内部 ID 或请求签名。不要把敏感值粘贴进浏览器工具。正确做法是创建脱敏副本：把 token 替换成 `REDACTED_TOKEN`，使用示例邮箱，缩短长 ID，并且只有在数组长度影响问题时才保留真实长度。
好的脱敏会保留调试信号。坏的脱敏会改变字段类型、删除嵌套，或者移除真正触发错误的值。如果 bug 与长字符串有关，就保留同长度级别的模拟字符串；如果 bug 与字段缺失有关，就不要为了样例好看而补上字段。
调试检查清单
- 先校验 JSON 语法，再判断业务含义。
- 先修第一个语法错误，再看后续报错是否仍存在。
- 检查 trailing comma、单引号、注释、非法转义和未闭合字符串。
- 分别保留原始响应、格式化响应和最小复现样例。
- 只有确认存在 JWT 或 Base64 包装时才解码。
- 脱敏时保留字段类型、层级和触发错误的结构。
- 合法 JSON 仍要对照 API schema 或应用契约。
FAQ
Formatter 可以自动修复非法 JSON 吗？
它可以让合法 JSON 更易读，也可以指出语法错误位置，但不应该静默帮你编造缺失结构。你仍然需要理解并修复生产方或复制样例的问题。
为什么 JSON 合法，API 请求仍然失败？
语法合法只说明文本是 JSON。API 还可能要求特定字段、类型、枚举值、日期格式、认证信息或 schema 规则。
可以把 API JSON 粘贴进在线工具吗？
只有非敏感数据可以。生产 payload 应先脱敏，移除 secret、token、个人数据、客户标识和内部凭据。
为什么解码后 JSON 外面还有一层引号？
生产方可能把一个 JSON 字符串再次序列化，形成双重编码。此时要检查序列化步骤，而不是只格式化最终文本。