JSON（JavaScript Object Notation，JavaScript对象表示法）是一种轻量级的数据交换格式。它于2001年由Douglas Crockford正式提出，自2006年正式标准化（ECMA-404，2013年首次发布，后更新至第二版2017年）以来，已成为现代互联网数据表示的的事实标准。它源于JavaScript对象字面量，但完全语言独立，几乎所有编程语言都有高效的JSON库支持。JSON的设计哲学是“简洁至上”：最小化冗余、易解析、人类可读。

截至2025年12月，JSON主导RESTful API、NoSQL数据库（如MongoDB、CouchDB）、配置文件（npm、Composer）、实时通信（WebSocket）和前端状态管理（Redux）。尽管有竞争者如Protobuf（二进制、高性能）、MessagePack或YAML（更人性化），JSON因其通用性和生态仍无可替代。

本篇文章将带你深入 JSON 的底层逻辑、性能瓶颈、安全性以及它在现代架构中的高级应用。

1. 什么是 JSON？

JSON 全称是 JavaScript Object Notation（JavaScript 对象表示法）。

虽然名字里带着 JavaScript，但它现在是一种独立于语言的标准（RFC 8259）。无论你使用的是 Python、Java、C++ 还是 Go，都能轻松读写 JSON。

比喻： 如果 XML 是装载货物的“木质大板箱”（稳固但重），那么 JSON 就是“轻便的顺丰快递袋”。它去掉了冗余的标签，只保留最核心的数据，因此体积更小，传输更快。

2. JSON 的基本语法

JSON严格遵守ECMA-404规范，JSON 的核心非常简单，只有两种基本结构：

键值对 (Key-Value Pairs)：用花括号 {} 包裹，表示一个“对象”。
列表 (Arrays)：用方括号 [] 包裹，表示一个“数组”。

典型的 JSON 示例：

JSON

{
  "name": "张三",
  "age": 25,
  "isStudent": false,
  "hobbies": ["编程", "羽毛球", "摄影"],
  "address": {
    "city": "北京",
    "street": "朝阳路"
  }
}

JSON的核心规则

键必须用双引号包裹：单引号无效。
值只能是上述6种类型：不支持函数、日期（需转为字符串）、undefined。
逗号分隔：键值对或数组项用逗号,分隔，最后一项后无逗号。
大小写敏感：True无效，必须小写true。
无注释：标准JSON不支持注释（虽有些解析器宽容）。
编码推荐UTF-8：支持Unicode字符（如中文）。

无效JSON示例：缺少引号、尾随逗号等会导致解析错误。

3. JSON 支持的数据类型

JSON 支持以下 6 种基础数据类型：

String（字符串）：必须用双引号，如 "Hello"。
Number（数字）：支持整数和浮点数，如 42 或 3.14（不区分int/float）。不需要双引号，不支持 NaN、Infinity 或 undefined。
Object（对象）：嵌套的花括号 {...}。
Array（数组）：嵌套的方括号 [...]。
Boolean（布尔值）：true 或 false。
null：表示空值。

对于时间格式，JSON 官方并不支持 Date 类型。通常需要转换成 ISO 8601 字符串（如 "2025-12-28T15:00:00Z"）或 Unix 时间戳。

JSON 默认使用 UTF-8 编码，Unicode 友好，天生支持多语言环境。

4. JSON Schema：为“模式缺失”正名

JSON 被称为“无模式”（Schemaless）格式，这在快速开发中是优势，但在大型工程中却是隐患。JSON Schema 填补了这个空白，它允许你像定义数据库表结构一样定义 JSON 的规格。

通过 JSON Schema，你可以规定：

哪些字段是必填的。
数值的取值范围（如 age 必须在 0-150 之间）。
字符串的正则匹配（如 email 格式）。
数组的长度限制。

这使得 JSON 在接口测试和自动化文档（如 Swagger/OpenAPI）中具备了工业级的鲁棒性。

5. 解析性能：序列化与反序列化

在高性能场景下，JSON 的解析成本不容忽视。

序列化 (Serialization)：将对象转换为字符串。
反序列化 (Deserialization)：将字符串还原为内存中的对象。

性能优化策略：

流式解析：对于超大 JSON 文件，不应一次性加载进内存，而应使用流式解析器（如 Java 的 Jackson Streaming 或 Python 的 ijson）。
避免冗余：JSON 是文本格式，字段名（Key）在每个对象中都会重复出现。在带宽敏感场景下，开启 Gzip/Brotli 压缩 通常能减少 60%-80% 的体积。

6. JSON 进阶：JSONB 与二进制格式

为了解决 JSON 的存储和查询效率问题，现代数据库（如 PostgreSQL 和 MongoDB）引入了进阶方案。

JSON vs. JSONB

在 PostgreSQL 中：

JSON：存储原始文本，存入快，但查询时需要重新解析，速度慢。
JSONB (JSON Binary)：存储二进制格式。存入时会进行预处理，支持索引（如 GIN 索引），查询速度极快。

文本 vs. 二进制 (Protobuf/BSON)

当 JSON 的体积和解析速度成为瓶颈时，工程师会转向二进制格式：

BSON：MongoDB 使用的扩展格式，支持更多数据类型（如字节数组）。
Protocol Buffers (Protobuf)：Google 推出，比 JSON 更小、更快，但牺牲了人类可读性，适用于微服务内部通信。

7. 安全隐患：JSON 并不总是安全的

虽然 JSON 本身是纯数据，但处理不当会导致严重安全问题：

JSON 注入：如果直接将不可信的字符串拼接进 JSON 构造流程，可能导致逻辑错误。
解析器炸弹 (JSON Bomb)：通过深度嵌套的对象（如 { "a": { "b": { "c": ... } } }）导致解析器耗尽内存和 CPU，引发拒绝服务攻击（DoS）。
eval() 的风险：在旧版 JS 代码中，使用 eval() 来解析 JSON 会导致任意代码执行攻击。始终使用 JSON.parse()。

8. JSON的局限与演进

局限：无原生日期/二进制（需Base64）、数字精度（大整数易丢失）、无注释。
解决方案：JSON-LD（语义网）、JSON Patch（RFC 6902，部分更新）、JSON Merge Patch。
未来：二进制替代如CBOR（Concise Binary Object Representation，RFC 8949）在IoT兴起；但JSON生态太强，短期无取代者。

9. 为什么 JSON 击败了 XML？（JSON vs. XML）

在 Web API 开发中，JSON 已经几乎取代了 XML，原因如下：

特性	JSON	XML
可读性	非常直观，像人类说话	标签密集，看起来比较杂乱
体积	较小（没有冗余的结束标签）	较大
解析速度	极快（JS 原生支持，解析即对象）	较慢（需要复杂的 DOM 解析）
数据结构	完美对应数组和对象	需要转换成树状结构

在很多场景中，比如旧项目改造，我们需要把JSON格式数据转化成XML格式，或者把XML格式数据转化成JSON格式，可以使用 在线 XML和JSON互转工具 实现一键转换。

10. JSON 的常见用途

Web API 传输：当你刷抖音或朋友圈时，后台返回给手机的数据 99.0% 都是 JSON 格式。现代REST API几乎全部返回JSON（Content-Type: application/json）。
配置文件：很多现代软件（如 VS Code）使用 .json 文件来保存用户的个性化设置。
NoSQL 数据库：像 MongoDB 这样的数据库，直接以类似 JSON 的格式存储数据。
数据传输：Ajax、WebSocket等。

如有JSON格式化需求，大部分代码工具都支持JSON格式化，如VS Code、Notepad ++，在线格式化可以使用 JSON格式化工具

11. 总结

JSON 的成功在于它的简单。它不试图解决所有复杂的文档验证问题（那是 XML 的强项），它只想做一件事：用最少的字符，最清晰地表达数据。

JSON 深度解析：现代互联网的通用语言