关于JSON
从接口响应、配置文件到前后端联调，JSON 几乎无处不在。理解它的结构和边界，很多数据传递问题都会变得清晰。
JSON 是什么
JSON 全称是 JavaScript Object Notation，翻译过来就是 JavaScript 对象标记法。它是一种基于文本的开放式数据交换格式，用来在系统之间描述和传递结构化数据。和 XML 相比，JSON 写法更短、更轻量，也更容易阅读。
JSON 全貌：对象、数组、字段和值
JSON 的核心结构很少，主要由对象、数组和几种基础值组成。理解这几类结构后，就能看懂绝大多数接口响应和配置文件。
对象（Object）
对象使用大括号 {} 包裹，内部由键值对组成，键和值之间用冒号 : 分隔。例如 { "name": "John", "age": 30 }。
数组（Array）
数组使用中括号 [] 包裹，元素之间用逗号 , 分隔。例如 [ "apple", "banana", "orange" ]。数组常用于表示列表。
键值对
JSON 对象中的字段名必须使用双引号，字段值可以是字符串、数字、布尔值、null、对象或数组。
空数组、空对象和空值
"list": [] 表示列表存在但暂时没有元素；"list": null 表示这个字段当前没有值；{} 表示一个空对象。三者含义不同，接口文档里应写清楚。
下面展示一个 JSON 样例
JSON 的发展历程
JavaScript 诞生
Brendan Eich 创建 JavaScript，后来 JSON 借用了 JavaScript 对象字面量的写法，这为 JSON 的语法形态提供了背景。
ECMA-262 第三版发布
JSON 的语法基础来自 JavaScript 标准中的一个子集。json.org 对 JSON 的介绍中也明确提到，它基于 ECMA-262 第三版的一部分。
Douglas Crockford 推动 JSON 成形
Douglas Crockford 在 State Software 工作期间，将这种轻量数据格式整理、命名并推广。Chip Morningstar 也是 State Software 早期团队中的关键人物，参与了 JSON 早期形成过程。
json.org 上线
Douglas Crockford 注册 json.org 并发布 JSON 说明，让这种格式有了稳定的公开文档入口，也方便开发者引用和实现。
AJAX 和 Web API 推动 JSON 普及
AJAX 应用大量出现，前端页面需要频繁和服务端交换数据，JSON 因为体积小、解析方便，开始在接口响应中快速流行。
RFC 4627 发布
RFC 4627 的作者是 Douglas Crockford。它让 JSON 获得正式的互联网标准说明，application/json 媒体类型也被明确下来。
JSON.parse() 和 JSON.stringify() 进入 ECMAScript 5
JavaScript 原生支持 JSON 解析和序列化，前端开发者可以直接在浏览器里处理 JSON 字符串和对象。
ECMA-404 标准发布
JSON 的语法被进一步标准化，跨语言、跨平台使用更加稳定。
RFC 7159 更新 JSON 说明
JSON 的互联网标准文档继续演进，对可接受的 JSON 文本和互操作细节做了进一步整理。
RFC 8259 与 ECMA-404 第二版发布
RFC 8259 成为新的 JSON 互联网标准参考，ECMA-404 也发布第二版，JSON 的标准描述更加统一。
JSON Schema、OpenAPI 和云原生配置广泛使用 JSON
接口文档、参数校验、自动化测试、配置管理和云服务控制台中，JSON 与 JSON Schema、OpenAPI 等生态一起成为常用基础设施。
JSON 成为接口和配置的默认选择之一
REST API、前端请求响应、配置文件、日志数据、低代码平台和测试工具中，都可以看到 JSON。
JSON 对比 XML 的优势
- 简单：JSON 主要使用大括号、中括号、冒号和逗号，结构直观。
- 快捷：文本更短，接口传输时通常比 XML 更省空间。
- 易于理解：字段和值一眼能看出对应关系，新手上手快。
- 适合前后端协作：JavaScript 可以直接解析 JSON，其他语言也普遍支持。
JSON 本身的不足
不能添加注释
标准 JSON 不支持注释。配置文件如果必须说明字段含义，建议放到文档、README、JSON Schema 或额外说明字段中。
很多新手会把 // 或 /* */ 写进 JSON，结果解析时报 Unexpected token，这就是因为标准 JSON 不允许注释。
还不算最高效的数据格式
JSON 是文本格式，可读性很好，但解析和传输效率并不是最高。如果是极高吞吐、强类型、低延迟场景，Protobuf、MessagePack 等二进制格式可能更合适。
不过对大多数 Web 接口、后台管理系统、配置文件和调试场景来说，JSON 的可读性和通用性仍然非常划算。
常用语言 JSON 解析方法
解析 JSON 常见有两个方向：把 JSON 字符串变成语言里的对象，叫反序列化；把语言里的对象转成 JSON 字符串，叫序列化。
| 语言 | 反序列化 / 解析 | 序列化 / 转字符串 | 说明 |
|---|---|---|---|
| JavaScript | JSON.parse() | JSON.stringify() | 浏览器和 Node.js 原生支持。 |
| PHP | json_decode() | json_encode() | 接口开发和后端模板项目中常见。 |
| Java | Jackson / Gson | Jackson / Gson | 常用于 Spring Boot 接口入参和响应。 |
| Python | json.loads() | json.dumps() | 标准库 json 模块直接支持。 |
| C++ | nlohmann/json 等库 | dump() | 通常依赖第三方 JSON 库。 |
| Go | json.Unmarshal() | json.Marshal() | 标准库 encoding/json。 |
| Rust | serde_json::from_str() | serde_json::to_string() | 常配合 serde 使用。 |
JSON 字符串与 JSON 对象
JSON字符串
JSON 字符串本质是一段文本。例如 "{\"name\":\"Lin\"}" 是字符串，它看起来像对象，但程序还没有把它解析成可访问的数据结构。
从接口、文件、localStorage、日志中拿到的数据，很多时候最开始都是 JSON 字符串。
JSON对象
JSON 对象通常指程序解析后的对象结构。例如 JavaScript 中 JSON.parse("{\"name\":\"Lin\"}") 得到对象后，就可以通过 obj.name 读取字段。
字符串适合传输和保存，对象适合在程序里读取、修改和计算。JSON.parse() 和 JSON.stringify() 就是在这两种状态之间转换。
哪些地方会遇到 JSON
- 测试接口：接口测试工具里填写 JSON Body，查看 JSON 响应。
- REST API：前后端使用 JSON 传递用户、订单、支付、商品等数据。
- 对接接口：第三方开放平台通常用 JSON 描述请求参数和返回结果。
- 开发者模式网络面板：浏览器 DevTools 的 Network 中，请求与响应经常是 JSON。
- 配置文件：很多项目使用 package.json、tsconfig.json、appsettings.json 等 JSON 配置。
- 日志和埋点：服务端日志、前端埋点、数据上报也常用 JSON 表达结构化数据。
新手常见 JSON 错误
字段名没有使用双引号
错误写法是 { name: "Lin" }，标准 JSON 要写成 { "name": "Lin" }。
修复建议：字段名统一使用英文双引号，不要使用单引号。
对象或数组最后多了逗号
例如 { "name": "Lin", } 在标准 JSON 中是错误的。
修复建议：最后一个键值对或数组元素后面不要加逗号。
把空数组和 null 混用
"list": [] 表示空列表，"list": null 表示没有值，业务含义不同。
修复建议：接口文档中明确字段为空时使用 []、{}、null 还是空字符串。
JSON字符串没有反序列化就直接取字段
字符串不能直接当对象用，需要先解析。
修复建议：JavaScript 中先使用 JSON.parse(text)，再读取对象属性。
数字、金额和 ID 类型不统一
订单金额、超长 ID 如果在不同语言中用数字处理，可能出现精度问题。
修复建议：金额、高精度数字和超长 ID 可以按字符串传输，例如 "amount": "199.00"。
写在最后
技术成长不只在于会用工具，也在于能把概念讲清楚、把边界写清楚。
当你能把数据结构、接口约定和错误原因说明白，晋升所需的工程判断力也会慢慢长出来。