打开任意一个 App 抓包，或者看一眼网页请求的返回，十有八九是一坨带大括号的文本。那就是 JSON。它现在几乎是前后端、服务与服务之间交换数据的「普通话」。但十年前还不是这样——那时候 XML 更主流。JSON 凭什么赢？

一、它长什么样

JSON 只有两种结构：键值对（对象 {}）和有序列表（数组 []）。比如描述一个用户：

{
  "name": "张三",
  "age": 28,
  "tags": ["vip", "active"]
}

键必须是双引号字符串，值可以是字符串、数字、布尔、null、对象或数组。规则少、长得像 JS 对象，所以人和机器都好懂。

二、为什么干掉了 XML

XML 也能表达同样的信息，但要写一堆 <tag></tag> 开闭标签，又啰嗦又占空间。同样的内容，JSON 字符数通常少一大半，传输更快、肉眼更易读。在「数据要在网络上飞来飞去」的时代，这点优势被放大了。

再加上 JavaScript 原生能直接解析 JSON（JSON.parse），前端几乎零成本接入。天时（Web 兴起）+ 地利（JS 亲和）+ 人和（语法简单），让它成了事实标准。

三、它不是只属于程序员

很多人以为 JSON 是后端的事，其实它无处不在：

  • 配置文件（很多工具的设定就是 JSON）
  • 浏览器本地存储（localStorage 里存的常是 JSON 字符串）
  • 把数据导出再导入（比如两个系统对接）
  • 甚至你把一段结构化笔记备份，也可能存成 JSON

所以「能看懂 JSON」越来越像一种基础素养，不亚于看懂表格。

四、人写人读，最怕格式乱

JSON 对格式敏感：少个引号、多个逗号、括号不配对，就解析失败。手写一长串很容易出错。这时候 JSON 格式化工具 就派上用场——把压缩成一行的「毛线团」展开成带缩进的树状结构，哪里缺括号、哪个字段名拼错，一眼看穿。

很多接口返回是压缩过的（为了省流量），你拿到的就是一行密文。先格式化再看，效率天差地别。

五、它和「编码」常一起出现

JSON 本身只规定结构，不规定内容怎么编码。当数据里夹带二进制（图片、文件）或要塞进 URL、Cookie 这类对字符挑剔的地方时，常常先把内容做 Base64 编码再放进 JSON 字段。反过来，你看到 JSON 里一段看着像乱码的字符串，用 Base64 编解码 解一下，可能就是原图或原文本。

还有传输层：JSON 作为查询参数或表单值传时，里面的特殊字符（空格、引号、&）会破坏结构，得先 URL 编码 再传。理解了这层关系，调试「接口收到空值」「中文变乱码」这类问题就有思路了。

六、常见坑

  • 数字精度：超大整数（比如雪花 ID）在 JS 里可能丢精度，跨语言传递时要留意用字符串。
  • 日期：JSON 没有日期类型，通常传 ISO 字符串或时间戳，两端约定好别混。
  • null vs 缺字段：有的系统用 null 表示「有这个字段但为空」，有的直接不返回该字段，消费方要兼容两种。
  • 嵌套太深：为了「灵活」把结构套五六层，解析和阅读都痛苦，适度扁平更好。

七、一个实用姿势

和 JSON 打交道的最小工具链：拿到接口返回先格式化 → 看结构找字段 → 涉及二进制/传输先想编码。这三步习惯养成，你处理数据接口的速度会明显快起来，也不再怕那一坨大括号。

小结：JSON 胜在「简单 + 紧凑 + JS 亲和」，成了数据交换的通用语。它不只在后端——配置、存储、备份、接口处处有它。会格式化、懂编码、避开精度/日期坑，就能舒服地和这门「普通话」共事。