【JSON小白篇】数据交换的通用语言—JSON

json的实战用法可以参考：【JSON Python篇】通过代码操作 JSON

不管你用什么语言写后端，前端发过来的数据大概率长这样：{"username": "zhangsan", "password": "123456"}。这就是 JSON。

打开任何一个 Web API 的文档，请求和响应的格式几乎都是 JSON。配置文件是 JSON，数据库里存的结构化文本是 JSON，前后端之间传来传去的还是 JSON。这篇把 JSON 格式本身讲清楚：它是什么、有哪些规则、为什么它成了事实标准。

一、JSON介绍

1.1 JSON是什么

JSON（JavaScript Object Notation）是一种纯文本格式，用来表示结构化数据。长这样：

json 复制代码

{
  "name": "zhangsan",
  "age": 28,
  "skills": ["Python", "Flask"],
  "active": true
}

虽然名字里带 JavaScript，它确实是 2001 年从 JS 语法里提炼出来的，但今天它早就不是任何语言的专属了。Python 有 json 模块，Java 有 Gson/Jackson，Go 有 encoding/json，Rust 有 serde_json......几乎所有主流语言都内置或有成熟的 JSON 支持。

JSON 的全部内容就写在一页纸就够的规范里（json.org），这种极简是它能成为通用格式的根本原因。

1.2 语法规则：只有六种类型

JSON 的数据类型只有六种，记住这张表就掌握了全部语法：

类型	示例	说明
string	`"hello"`	必须用双引号，不能用单引号
number	`42`, `3.14`, `-1`	整数或浮点数，不支持 `0x`、`NaN`、`Infinity`
boolean	`true`, `false`	全小写，不是 `True`/`False`
null	`null`	表示"没有值"，不是 `None`、不是 `nil`
array	`[1, "two", true]`	有序列表，元素可以是任意类型
object	`{"key": "value"}`	键值对集合，键必须是双引号字符串

整个 JSON 世界就建立在这六块积木上。没有日期类型、没有二进制类型、没有注释，这些"缺失"是刻意为之的设计选择，后面会讲为什么。

一个完整的例子，六种类型全覆盖：

json 复制代码

{
  "user_id": 1,
  "username": "zhangsan",
  "email": null,
  "active": true,
  "scores": [95, 87, 92],
  "profile": {
    "bio": "Backend developer",
    "years": 3
  }
}

object 和 array 可以任意嵌套，所以 JSON 能表达很复杂的数据结构。但每个叶子节点最终都是 string、number、boolean 或 null。

二、JSON规则

JSON 语法很宽松，但有几条铁律不能违反，违反了解析器会直接报错：

2.1 键必须是双引号字符串

复制代码

错误 ❌  {name: "zhangsan"}
错误 ❌  {'name': "zhangsan"}
正确 ✅  {"name": "zhangsan"}

这是和 JavaScript 对象字面量的最大区别。JS 里键可以不加引号，JSON 里不行。

2.2 字符串必须用双引号

复制代码

错误 ❌  {'name': 'zhangsan'}
正确 ✅  {"name": "zhangsan"}

单引号在 JSON 里不合法。写 Python 的人特别容易踩这个坑，Python 里单双引号等价，JSON 里只认双引号。

2.3 尾部不能有逗号

复制代码

错误 ❌  {"name": "zhangsan", "age": 28,}
正确 ✅  {"name": "zhangsan", "age": 28}

最后一个元素后面不能有逗号。很多语言（JavaScript、Python、Go）都允许尾逗号，但 JSON 不行。

2.4 不能有注释

JSON 不支持任何形式的注释：没有 //，没有 /* */，没有 #。

这是 JSON 发明者 Douglas Crockford 的刻意决定。他认为注释会导致解析复杂化和滥用（比如把处理指令藏在注释里）。如果你需要带注释的配置文件，可以用 JSONC（VS Code 在用的格式）、YAML 或 TOML。

2.5 顶层必须是一个值

一个合法的 JSON 文档，顶层必须是上面六种类型之一。最常见的是 object {} 或 array []，但一个单独的 "hello"、42、true、null 也是合法的 JSON。

三、两种风格：紧凑 vs 格式化

同一份数据可以有两种写法，含义完全相同。

3.1 紧凑风格

一行搞定，没有多余空白：

json 复制代码

{"user_id":123,"name":"zhangsan","role":"user"}

3.2 格式化风格

有缩进和换行，人眼友好：

json 复制代码

{
  "user_id": 123,
  "name": "zhangsan",
  "role": "user"
}

JSON 规范不关心空白，解析器看到 {"user_id":123} 和 { "user_id" : 123 } 认为是完全一样的数据。但空白会影响文本内容本身，这在某些场景很关键。

比如对 JSON 文本做哈希或 Base64 编码时，同一个 object，紧凑格式和带空格的格式算出来的结果完全不同。多一个空格，编码就对不上。

3.3 什么时候用哪种？

读者是机器就紧凑，读者是人就格式化。

场景	选哪种	原因
API 请求/响应体	紧凑	省带宽，客户端收到后自己解析，不需要好看
存进 Redis / 数据库	紧凑	十万条数据，每条多几个空格就是几 MB 内存
签名、哈希、Base64 编码	紧凑	多一个空格结果就变了，格式必须固定
`package.json` 等配置文件	格式化	要用编辑器打开手动改，不好看就没法维护
日志输出	格式化	线上排查问题时需要快速肉眼定位字段
调试时 print 出来看	格式化	紧凑的一坨字符串根本读不动

四、JSON 为什么赢了

在 JSON 之前，数据交换的主流格式是 XML：

xml 复制代码

<user>
  <name>zhangsan</name>
  <age>28</age>
  <skills>
    <skill>Python</skill>
    <skill>Flask</skill>
  </skills>
  <active>true</active>
</user>

同样的数据，用 JSON：

json 复制代码

{
  "name": "zhangsan",
  "age": 28,
  "skills": ["Python", "Flask"],
  "active": true
}

差别一目了然：

	JSON	XML
可读性	接近自然语言	标签噪音大
体积	紧凑	开闭标签占大量空间
解析速度	快（结构简单）	慢（需要处理属性、命名空间等）
数据类型	原生区分 string/number/boolean	全是字符串，类型靠约定
学习成本	5 分钟	需要理解 DTD、Schema、XPath...

XML 不是没有优势，它支持注释、命名空间、混合内容（文本和标签穿插），在文档标记领域（HTML 就是 XML 的近亲）依然无可替代。但对于"两个程序之间传结构化数据"这个场景，JSON 用更少的字符做到了同样的事。

2005 年之后，随着 AJAX 和 REST API 的普及，JSON 迅速取代 XML 成为 Web API 的事实标准。今天你打开任何一个公开 API 的文档，返回格式几乎都是 JSON。

五、JSON 在哪里

JSON 不是某一个环节的专属工具，它渗透在整个技术栈里。从用户点击按钮到数据落盘，中间流转的大概率都是 JSON。

知道了语法，再看看你日常开发中哪些地方其实已经在跟 JSON 打交道了，可能比你想的多得多。

5.1 API：前后端之间的普通话

你用浏览器登录一个网站，点击"登录"按钮，浏览器发出去的请求体长这样：

json 复制代码

{"username": "zhangsan", "password": "123456"}

服务器处理完，返回的响应体也是 JSON：

json 复制代码

{"code": 200, "message": "登录成功", "token": "eyJhbGciOi..."}

这就是 REST API 的日常，请求是 JSON，响应也是 JSON。打开 GitHub、微信、支付宝的开放平台文档，接口格式清一色都是它。

5.2 配置文件：程序的"说明书"

用过 VS Code 的都见过 settings.json；写过前端项目的都改过 package.json；用 TypeScript 就有 tsconfig.json。这些配置文件选 JSON 的原因很简单：结构清晰、所有语言都能解析、不需要额外装库。

json 复制代码

{
  "name": "my-project",
  "version": "1.0.0",
  "scripts": {
    "dev": "vite",
    "build": "vite build"
  }
}

不过 JSON 不支持注释这一点在配置场景里确实不方便，所以 VS Code 实际用的是 JSONC（JSON with Comments），tsconfig.json 也允许注释。严格来说它们不是标准 JSON，但解析器做了兼容。

5.3 数据库：不只是关系型的世界

MongoDB 整个数据模型就建立在类 JSON 的文档结构上，存进去的每条数据就是一个 JSON object。PostgreSQL 有专门的 jsonb 字段类型，可以直接在 SQL 里查询 JSON 内部的键值。Redis 的值是字符串，实际项目中存的往往就是 JSON 序列化后的结果。

sql 复制代码

-- PostgreSQL：直接查 JSON 里的字段
SELECT data->>'username' FROM users WHERE data->>'role' = 'admin';

5.4 日志：给机器看的也是 JSON

传统日志是一行行自由文本，人能读但机器很难解析。现代日志系统（ELK、Loki、CloudWatch）越来越多地采用结构化日志，每条日志就是一个 JSON object：

json 复制代码

{"timestamp": "2026-03-26T08:30:00Z", "level": "ERROR", "service": "auth", "message": "token expired", "user_id": 123}

好处是显而易见的：可以按 level 过滤、按 service 聚合、按 user_id 追踪，不需要写正则去文本里"捞"信息。

六、总结

JSON 是纯文本格式，只有六种数据类型：string、number、boolean、null、array、object
键必须用双引号字符串、尾部不能有多余逗号、不能含注释，规则少但严格
紧凑和格式化两种风格，含义相同，但文本内容不同（影响编码和签名）
它赢了 XML，因为更简单、更轻量、解析更快
在 Web 开发中，JSON 不是某个具体技术的附属，而是数据交换的通用语言

知道了 JSON 是什么，下一步就是用代码操作它，怎么把程序里的数据结构转成 JSON 字符串、怎么把 JSON 字符串解析回来。