JSON为什么适合交换接口数据？先理解文本与类型约定

接口返回一段文本，前端解析失败

排查一个联调问题，后端说返回的是标准 JSON，前端说解析不了。

把响应体打出来一看，末尾多了一个逗号。就这一处，卡了两个小时，谁也没想到是这个。

JSON 本质就是文本

先把它看成字符串，很多疑问就消失了，包括为什么不能写注释。

它不是一种传输协议，也不是数据库格式，就是一串字符，按约定排好。

用花括号表示对象，用方括号表示数组，键值之间用冒号，元素之间用逗号，键必须是字符串。

只要遵守这套写法，谁都能读，谁都能生成，出了错也容易定位到具体字符。

宝塔拨测工具盒：站长工具与 IT 工具入口

六种类型就够用

类型搞对，比字段名起得漂亮重要，类型一错，下游全是连锁反应。

字符串必须用双引号，单引号不合法，这一点和 JavaScript 对象字面量不一样。

数字不加引号，加了就变成字符串，前端做加法会变成拼接，很难查。

布尔和 null 是小写，写成 True 就错，Python 里合法，JSON 里不合法。

对象和数组可以互相嵌套，但不能有注释，注释是最常见的「看起来对」的错误。写出来的东西贴进宝塔拨测的开发者工具集的 JSON 格式化里，能排版就说明语法没错。

为什么适合交换

优势不玄，都是实际用出来的，不是文档里吹出来的。

语言无关，Python 和 Go 读出来是同一份结构，不用为每种语言写一套解析。

比 XML 短，字段名一眼能看懂，日志里也不会占满整屏。

浏览器原生支持解析，前端不用额外依赖，这点在排查时特别省事。

最容易踩的坑

这些坑我都踩过，一个比一个隐蔽，最难的是最后那个。

最后一个元素后面多写逗号，这是出现频率最高的错误。

中文引号混进去，肉眼看不出差别，报错位置还常常指错行。

大整数被当成浮点数，末位精度丢了，订单号一长就出事。

时间格式不统一，一边是时间戳一边是字符串，对账时才发现差了一天。

怎么快速验

先分语法和业务，两步走，别一上来就翻代码。

把响应体贴进格式化工具跑一遍，语法层面的事一眼就能看出来。

格式化了但业务报错，那就是类型或字段约定的问题，不是语法问题，别在括号里找答案。

两边分开看，排查会快很多，也更容易跟对方说清楚问题在哪，省得互相甩锅。

把约定记住，联调能省一半时间。

省下来的时间，够多跑几轮测试。

这就是这类基础知识的价值。

下次再遇到解析失败，先看逗号。