JSON 格式化与校验
纯前端：粘贴 JSON，一键美化、压缩或校验。数据不出你的浏览器，不联网、不记录。
怎么用
把任意一段 JSON 粘进左边文本框，点 格式化 按层级展开；点 压缩 去掉所有空白；点 校验 只检查能不能解析，并在出错时标出第几行第几列。缩进量可以选 2 格或 4 格。
为什么运维天天要格式化 JSON
你几乎每天都会撞上挤成一行的 JSON：
- 接口调试：
curl出来的响应经常是一整行，字段嵌套三层以上根本没法看，格式化之后结构一目了然。 - 配置文件：
kubectl -o json、Prometheus 的config.json、各种 SDK 的配置，肉眼核对层级必用。 - 日志排错：结构化日志（JSON line）里一个字段写错类型，下游解析就崩，先格式化再比对最快。
- 文档与工单：把一段配置贴进工单前格式化，对方一眼看懂，少来回。
最常见的三类报错
| 报错现象 | 根因 | 处理 |
|---|---|---|
Unexpected token } 在末尾 |
数组或对象最后一个元素后多了逗号 | 删掉那个逗号 |
Unexpected token ' 或字符串没闭合 |
用了单引号，JSON 只认双引号 | 改成双引号 |
Unexpected token / 或 # |
写了 // 或 # 注释，JSON 标准不允许 |
删掉注释再校验 |
工具会在报错信息里给出字符位置，我们把它换算成「第几行第几列」，顺那一列往前看一个字符，基本都能逮到。
几个容易踩的坑
BOM 头：Windows 记事本保存的 UTF-8 会在文件头塞三个不可见字节（EF BB BF），粘进来的 JSON 第一个字符就变成乱码，解析必失败。遇到「第一个字符就报错」先怀疑 BOM，用 sed -i '1s/^\xEF\xBB\xBF//' 或编辑器转成无 BOM UTF-8。
大数精度：JavaScript 的 JSON.parse 把数字读成双精度浮点，超过 2^53（约 9×10¹⁵）的整数会丢精度。订单号、雪花 ID 这类长整型，必须让后端返回字符串，否则你格式化完看到的数字可能已经不对了。本工具对字符串原样保留，不会动它。
键名必须带引号：{name: "ops"} 在 JavaScript 对象里合法，但 JSON 要求键名也是双引号字符串 { "name": "ops" }。这也是「浏览器能跑、校验报错」的高频原因。
重复键：JSON 标准允许重复键，但解析时不同实现保留最后一个还是第一个不一致。配置里别写重复键，出问题极难查。
一个真实的排错例子
假设你拿到一段压成一行的接口响应，肉眼完全看不出问题：
{"code":0,"data":{"user":{"id":12345678901234567890,"name":" ops ","tags":["vip",]},"list":[{"sku":"A1","price":9.9},{"sku":"A2","price":19.9}]},"msg":"ok"}
粘进来点 校验，工具立刻报「第 1 行第 60 列 unexpected token」。顺着第 60 列往前看，发现 "tags":["vip",] 多了个尾逗号——这就是数组里最后一个元素后的多余逗号。删掉后重新格式化，字段层级清清楚楚，user.id 这个超长整型也以字符串原样保留，不会被悄悄改值。
这个例子里还有两个隐藏点：用户名 " ops " 前后有空格（上游 trimming 没做）、id 是超过 2^53 的长整型（必须字符串）。格式化不解决这些业务问题，但它把结构摊开，让你一眼看到「哪里不对劲」。
本工具和 jq 是什么关系
不是替代，是互补：
- 浏览器里随手用：临时拿到一段 JSON、在工单里贴配置、在没装 jq 的机器上快速看结构，打开网页就够，这是本工具的定位。
- 命令行批量处理：要在脚本里提取字段、过滤数组、改完写回文件，用
jq更合适，例如jq '.data.list[] | select(.price>10)'直接筛出高价商品。 - CI 里校验：提交配置前跑
jq empty config.json能在流水线里拦住非法 JSON，比人工粘贴更稳。
本工具负责「人看着舒服」，jq 负责「机器批量跑」，两者都该进你的工具箱。
在配置管理里的用法
改配置最怕改出问题还不知道。一个稳妥的流程：
- 从集群导出配置（
kubectl get ... -o json或 Prometheus 的config.json）； - 粘进本工具格式化，按层级通读一遍，确认改的地方结构对；
- 改完点 压缩，把紧凑结果贴回编辑器或命令行；
- 提交前再用校验挡一道，避免尾逗号、单引号这类低级错误混进生产配置。
结构化日志、CI 流水线里的工件、各种 SDK 的配置文件，套路都一样：先格式化看清楚，再动手。
还有几个容易忽略的坑
转义字符：JSON 字符串里双引号要写成 \"，换行要写成 \n，反斜杠要写成 \\。从别的语言拼字符串时最容易漏转义，报的错往往指向字符串中间某个正常字符，其实是前面的转义错了。
Unicode 转义：表情、生僻字可能被编码成 \uXXXX。格式化本身不影响，但如果你靠「肉眼数长度」判断内容，别被转义序列骗了——它占的是 6 个字符位，实际是一个字。
科学计数法：极小或极大的数可能被解析器显示成 1e-7、9.9e20，这仍是合法数字，但下游若按字符串比较就会出偏差。需要精确时让上游用字符串表达。
null 与缺失："x": null 和「字段不存在」在 JSON 里是两回事，但很多解析库会混为一谈。排查「为什么这个字段没生效」时，先确认它是 null 还是压根没传。
数字还是字符串：端口 8080、版本 1.0、区号 010，写成数字还是字符串，严格消费者判定不同。配置里养成「语义上是标识或编号就套引号」的习惯，能少很多诡异 bug。
一句话：格式化只是把结构摊开让人看清楚，它不修复业务错误，但能让你在三十秒内定位「到底哪一行哪一段不对」。把它当排错的第一步，而不是最后一步。
相关教程
- OpenTelemetry 统一遥测：Trace/Metric/Log 采集 — 结构化日志、指标、链路的字段规范与接入，格式化只是第一步
- LLM 服务可观测 — 接口返回的 JSON 结构怎么看、怎么排错
- Cloudflare 隧道自建 — 配置文件里 JSON 段多，格式化后再改更稳