JSON 与数据处理指南
JSON 格式化报错与大整数精度排查
排查单引号、尾逗号和转义错误，区分格式化与修复，并避免长整数 ID 在解析时被四舍五入。
先看报错位置
标准 JSON 的键名和字符串使用双引号，不接受注释、单引号、尾逗号、undefined 或 NaN。先看报错行列，再检查它前面的逗号、引号和括号。
格式化只调整排版，不会把错误语法变成合法 JSON。包含 JSON 的字符串和 JSON 对象是不同值；输入是带引号的转义字符串时，使用字符串转换功能，不要手动删除反斜杠。
{"name":"Ada","active":true,"items":[1,2,3]}长整数 ID 要保留精度
JavaScript Number 能精确表示的整数上限是 9007199254740991；JSON 格式本身没有这个上限。用普通 JSON.parse 解析下面的示例，ID 在格式化前就会被舍入。
本站普通 JSON 工作区保留数值原文。格式化后检查 ID 末尾仍为 993。跨系统 API 中，不参与算术的 ID 可以约定为字符串。JSON5 和部分转换库有不同精度边界。
{"id":9007199254740993,"name":"example"}修复后必须核对变化
先用格式化确认输入是否符合标准 JSON。来源明确是 JSON5 时选择 JSON5；来源是损坏 JSON 时选择修复，并查看修复差异。修复可能推断缺失的标点，使用结果前要核对。
重复键名不适合数据交换：RFC 8259 建议名称唯一，不同解析器处理重复键的行为可能不同。应在源数据中解决重复，不能认为排版后的结果保留了两个值。
推荐操作顺序
把原文粘贴到 JSON 格式化，先解决语法错误；核对长整数 ID，切到树形或表格检查结构，再复制或下载完整结果。
用 JSON 对比核对结果与预期文档。格式化不等于 Schema 校验；API 有 Schema 时，还需要单独验证字段结构和类型。