为什么 JSON 总是难以阅读

每个接口返回、每份配置文件、每行日志都是 JSON。压缩后它是一整块字符墙；格式化之后同样的数据两秒就能扫完。数据完全相同，差的只是空白——这也是「JSON 格式化」成为开发者最常用搜索之一的原因。

格式化、压缩、校验的区别

操作 改什么 什么时候用
格式化 加缩进和换行 阅读、评审、排查问题
压缩 去掉所有多余空白 传输、存储配置
校验 不改内容，只报语法错误 提交请求体或配置文件之前

这三件事在 JSON 格式化工具 里都只差一次点击，而且全程在浏览器本地完成。

什么才算合法的 JSON

JSON 的语法非常小，而且比 JavaScript 严格得多：

  • 键名必须用双引号包起来
  • 字符串必须用双引号，单引号不合法
  • 不允许多余的逗号
  • 不允许注释（// 和 /* */ 都不行）
  • 值只有这几种：对象、数组、字符串、数字、true、false、null
  • 数字不能有多余的前导零，NaN / Infinity 也不是合法值

如果你写过 JSON5、JSONC（VS Code 配置）或者 JavaScript 对象字面量，其中一些习惯在 JSON 里是非法的。

最常踩的五个错误

1. 多了一个逗号

{
  "name": "NavProject",
  "version": "1.0",
}

"1.0" 后面那个逗号，是 JSON 报错的第一大来源。

2. 用了单引号

{ 'name': 'NavProject' }

JavaScript 合法，JSON 非法。

3. 键名没加引号

{ name: "NavProject" }

同样：JavaScript 合法，JSON 非法。

4. 写了注释

在配置里加一句 // TODO，然后程序启动失败。标准 JSON 没有注释语法，要么删掉，要么换一种允许注释的格式。

5. 内容被截断或拼接

两个对象粘在一起，或者从日志里复制时被截断。抓日志的时候最常遇到这种。

怎么读懂 JSON 报错

浏览器和 Node 的报错通常长这样：

Unexpected token } in JSON at position 84

这里的 position 是从字符串开头算起的字符偏移量，不是行号。要么自己数，要么交给工具：格式化工具 会直接告诉你 第 N 行第 M 列，这才是修复时需要的信息。

一套顺手的流程

  1. 把原始内容粘进 JSON 格式化工具
  2. 点「校验」，先确认能不能解析
  3. 点「格式化」看结构——多数时候你会发现是某个键写错或层级放错
  4. 回到源头修改，只在传输或存储时点「压缩」
  5. 仓库里存格式化版本，压缩放到构建或传输环节做

关于体积

压缩通常能省 10%～30%，具体取决于嵌套深度。这点节省本身意义有限，因为传输时的 gzip 压缩率高得多。压缩真正的价值在于一致性：避免因空白差异产生的合并冲突，也让体积可预期。

常见问题

格式化会改变数据吗？ 不会。字符串之外的空白在 JSON 中是可忽略的，格式化和压缩都是无损的。

JSON 允许重复的键吗？ 规范没有明确禁止，但行为未定义——多数解析器保留最后一个值。别这么写。

为什么我的内容在 JavaScript 里能用，校验却不过？ 因为你写的不是 JSON，而是 JavaScript 对象字面量。先用 JSON.stringify(obj) 转换一下。

这个工具会上传数据吗？ 不会，解析用的是浏览器自带的 JSON 解析器，离线也能用。

相关阅读