先看报错里的位置信息
解析器的报错通常带行号与列号（position / line / column），这是最值钱的信息：先把范围锁到一行，再看这一行缺了什么。注意两点：一是不少解析器报的位置是「发现异常的位置」，真正的错误可能在它前面一行（少了一个逗号或引号，往往在下一行才暴露）；二是如果文件被压缩成一行（例如某个接口返回），行号就没用了，先格式化展开再定位。格式化还能顺带暴露层级错误，比如多了一层不该有的数组。
五类最常见错误
一、尾随逗号：{"a": 1,} 不合法，JSON 比 JavaScript 严格得多。二、单引号：键与字符串都必须用双引号，'a': 'b' 一定报错。三、键没加引号：{a: 1} 是 JavaScript 的写法，JSON 里 key 必须带双引号。四、注释：JSON 标准不支持 // 与 /* */，需要注释时请用 JSON5 或干脆换成 YAML。五、转义问题：字符串里的双引号要写成 \\"，反斜杠要写成 \\\\，Windows 路径 C:\\Users 直接写会得到意外结果。这五类覆盖了绝大多数报错，按顺序排查通常一分钟就能结束。
中文与不可见字符
中文本身没问题（UTF-8 完全支持），但三种「看不见」的情况会让解析器困惑：一是 BOM 头（文件开头多出的 \\uFEFF），从某些编辑器或 Excel 导出的文件常带，删掉即可；二是全角引号与全角逗号（“ ” ，），从聊天软件或文档里复制 JSON 时极易带入，肉眼几乎看不出区别；三是零宽字符（\\u200B）与不换行空格（\\u00A0），它们在键名里出现时表现为「值明明一样却匹配不到」。排查方式很直接：把可疑片段复制到能看到字符码的工具里对照，或先做一次不可见字符清理。
特殊值与精度问题
JSON 只接受 null、布尔、数字、字符串、数组与对象，因此 NaN、Infinity、undefined 都不合法，需要改成 null 或字符串表达（例如 "NaN"）再约定解析规则。日期没有专门类型，实践中统一用 ISO 8601 字符串（2026-09-24T10:00:00+08:00），避免时区歧义。最容易踩的坑是大整数：超过 2^53 的整数（例如 19 位订单号、雪花算法 ID）在 JavaScript 里会丢精度，必须用字符串传输——接口文档里最好直接标注类型，否则前端拿到的那一刻就已经错了。
嵌套很深怎么定位
层级很深时，逐层删减比盯着看更有效：从最外层开始，把可疑分支整体删掉，看是否能通过校验，能通过说明错误在被删掉的片段里，二分下去几轮就能锁定。也可以先把格式化后的文本按缩进折叠，检查括号是否成对：常见的「少一个 }」会让解析器在文件末尾报错，而行号指向最后一行，容易误判。如果结构本身是数组套对象再套数组，建议先画一遍层级再动手。
推荐的处理顺序
第一步格式化：把压缩的内容展开，层级一目了然，报错行号也可用。第二步校验：确认语法合法，同时清理不可见字符。第三步转换：把校验通过的 JSON 转成 YAML、CSV 或目标语言的数据类型定义（TypeScript interface、Go struct、Java record 等），减少手工抄写字段名导致的错误。全过程都在浏览器本地完成：接口返回里常有手机号、订单号与内部字段，粘贴到陌生网站的风险比想象中大，这也是我们坚持不联网的原因。
想马上动手：把出错的 JSON 粘进 JSON 格式化与校验 看报错位置与层级；确认无误后用 JSON 转 TypeScript/Go/Java 生成类型，需要给后端同事时用 JSON 与 YAML 互转。Try it now: paste the failing JSON into the JSON formatter and validator to see the error position and structure, generate typed models with JSON to TypeScript/Go/Java, and hand YAML to colleagues via JSON ↔ YAML.
常见问题
JSON 和 JavaScript 对象字面量有什么区别？
JSON 是数据格式，键必须用双引号、不允许尾随逗号、不允许注释、不允许 undefined 与函数；JS 对象字面量宽松得多。用 JS 语法写 JSON 是报错的第一大来源。
为什么我的大整数精度丢了？
JavaScript 的 Number 只能安全表示 2^53 以内的整数，19 位 ID 会被四舍五入。请让接口用字符串返回，或在解析时使用 BigInt 与专门的库。
很大的 JSON 能处理吗？
几 MB 没问题，解析与格式化都在本地内存中完成。更大的文件（几十 MB 以上）建议用脚本处理，浏览器里容易卡顿。