开发中跟 JSON 打交道是家常便饭。后端返回的接口数据、配置文件、日志里的结构化字段——到处都是 JSON。但真正让人头疼的不是 JSON 本身，而是那些压缩成一行的、嵌套五六层的、还夹着语法错误的 JSON 字符串。
打开浏览器控制台手动 JSON.parse() 再 JSON.stringify(data, null, 2)？能用，但效率太低。装个 VS Code 插件？可以，但有时候你只是想快速看一眼某个 API 返回的数据结构，没必要切到编辑器。
这篇文章聊聊在线 JSON 格式化工具能帮你做什么，以及一些容易被忽略的实用技巧。
为什么需要专门的 JSON 格式化工具
你可能觉得 JSON 格式化很简单，随便找个工具就行。但实际开发中遇到的场景比"美化一下"要复杂得多：
场景一：接口调试
调 API 的时候，响应体经常是压缩过的。如果数据结构复杂（比如分页列表嵌套对象），直接看原始字符串基本不可能。你需要的是快速展开、折叠、定位到某个字段。
场景二：日志排查
生产环境的日志里经常有 JSON 格式的上下文信息。从 Kibana 或者日志文件里复制出来的 JSON，可能带有转义字符（\" 变成了 \\"），也可能被截断了一半。你需要工具能识别并提示这些问题。
场景三：配置文件检查
package.json、tsconfig.json、各种 CI/CD 的配置文件——改完之后想确认语法没问题，特别是手动编辑时容易漏掉逗号或多加了一个逗号（trailing comma）。
场景四：数据对比
两份 JSON 结构差不多，但某些字段值不同，人肉比对效率极低。
这些场景的共同点是：你需要一个随时打开、无需安装、能处理各种"脏数据"的工具。
核心功能拆解
一个好用的 JSON 格式化工具不只是做缩进美化。以 AnyFreeTools 的 JSON 格式化工具 为例，看看几个核心功能的实际用途。
语法校验与错误定位
直接粘贴 JSON，工具会实时检查语法。比较关键的是错误定位能力——不是只告诉你 "Unexpected token"，而是指出具体是第几行、第几个字符出了问题。
常见的 JSON 语法错误：
{
"name": "test",
"version": "1.0.0",
"scripts": {
"build": "tsc",
"dev": "vite",
}
}
这段 JSON 在 JavaScript 的 JSON.parse() 里会直接报错（第 6 行 "vite", 后面多了逗号，标准 JSON 不允许 trailing comma），但错误信息只会告诉你 "Unexpected token } in JSON at position xxx"，不够直观。好的格式化工具会高亮标出问题行，明确指出错误类型。
另一个常见坑是单引号。JSON 规范要求必须使用双引号，但从 Python repr() 或 JavaScript console 复制出来的数据经常带单引号。有些工具能自动修正，有些只会报错。
语法高亮
格式化后的 JSON 带有语法高亮，不同类型的值（字符串、数字、布尔值、null）用不同颜色标识，嵌套层级一目了然。这比浏览器控制台的纯文本输出直观得多，特别是处理深层嵌套结构时。
压缩（Minify）
格式化的逆操作。把美化后的 JSON 压缩成一行，去掉所有空白字符。用途包括：
- 准备 API 请求体（减少传输体积）
- 存入数据库的 JSON 字段
- 写入日志时减少存储占用
压缩率取决于原始 JSON 的缩进级别和数据结构。一般来说，2 空格缩进的 JSON 压缩后体积能减少 15%-30%（估算值，取决于嵌套深度和字段数量）。
数据对比技巧
做数据对比时，如果两份 JSON 的 key 顺序不同，直接做文本 diff 会产生大量噪音。一个实用技巧是先用 jq -S . 按 key 排序，再对比：
jq -S . a.json > a_sorted.json
jq -S . b.json > b_sorted.json
diff a_sorted.json b_sorted.json
或者直接使用 JSON Diff 工具 做语义级别的对比，自动忽略 key 顺序差异。
进阶用法：JSONPath 查询
如果你处理的 JSON 数据量比较大（几百 KB 甚至几 MB），手动翻找字段就不现实了。JSONPath 查询可以用路径表达式从 JSON 中精确提取数据，语法类似 XPath。
常用的表达式：
$.store.book[*].author -- 所有书的作者
$..price -- 所有层级中的 price 字段
$.store.book[?(@.price<10)] -- 价格小于 10 的书
AnyFreeTools 提供了独立的 JSONPath 查询工具，支持实时输入表达式并查看匹配结果。工作流程：先用格式化工具看结构，再用 JSONPath 精确提取需要的数据。
相关工具推荐
处理 JSON 不只是格式化。根据不同场景，你可能还需要这些工具：
JSON Schema 校验
如果你在写 API，需要验证请求体是否符合预期结构，JSON Schema 校验比手动检查靠谱得多。JSON Schema 验证工具可以在线测试你的 Schema 定义是否正确。
一个简单的 Schema 示例：
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"required": ["name", "email"],
"properties": {
"name": { "type": "string", "minLength": 1 },
"email": { "type": "string", "format": "email" },
"age": { "type": "integer", "minimum": 0 }
}
}
JSON Diff
对比两份 JSON 的差异。前面提到了排序后再对比的技巧，但如果工具本身支持语义级别的 diff（忽略 key 顺序，只关注值的变化），效率会更高。JSON Diff 工具可以试试。
CSV 与 JSON 互转
从 Excel 导出的 CSV 需要转成 JSON 导入系统？或者反过来，把 JSON 数据导出成 CSV 方便非技术人员查看？CSV 转 JSON 工具处理这类需求很方便。
YAML 与 JSON 互转
Kubernetes 配置、GitHub Actions——YAML 和 JSON 经常需要互转。YAML/JSON 互转工具省去手动转换的麻烦。
安全性：数据会不会泄露
这是使用在线工具时最该关注的问题。
AnyFreeTools 的 JSON 格式化工具在浏览器本地完成所有处理，数据不会发送到服务器。你可以验证这一点：打开浏览器的 Network 面板，粘贴 JSON 后观察是否有网络请求发出。纯前端实现意味着即使断网也能正常使用。
当然，如果你处理的是包含敏感信息的 JSON（比如包含 access token、用户数据），即使工具不上传数据，也建议用完后清空输入框，避免浏览器缓存或者有人看到你的屏幕。
和命令行工具的对比
开发者常用的命令行 JSON 工具主要是 jq：
# 格式化
cat response.json | jq .
# 提取字段
cat response.json | jq '.data.items[].name'
# 条件过滤
cat response.json | jq '.items[] | select(.status == "active")'
jq 功能强大，但学习曲线比较陡。它的语法不是 JSONPath，而是自己的一套 filter 语言。对于偶尔处理 JSON 的场景，在线工具的门槛更低；对于需要批量处理或写进脚本的场景，jq 更合适。
两者不是替代关系，而是互补。
实用技巧汇总
最后分享几个日常使用中的实用技巧。
处理转义字符串
从日志里复制的 JSON 经常带有 \" 转义，直接粘贴到格式化工具可能无法解析。解决方法是先做一次字符串替换：
# 用 sed 去除外层转义
echo '"{\"name\": \"test\"}"' | sed 's/\\"/"/g' | sed 's/^"//;s/"$//'
或者在浏览器控制台里：
// 把转义字符串还原为 JSON
const escaped = '{"name": "test", "age": 25}';
const parsed = JSON.parse(escaped);
console.log(JSON.stringify(parsed, null, 2));
大文件预处理
超过 1 MB 的 JSON 文件，浏览器可能会卡顿。建议先用 jq 过滤出需要的部分，再粘贴到在线工具里查看：
# 只提取 data.items 数组的前 10 条
cat huge.json | jq '.data.items[:10]'
# 只看顶层 key 结构
cat huge.json | jq 'keys'
URL 参数中的 JSON
有时候 URL 的 query parameter 里藏着 Base64 编码的 JSON。可以先用 Base64 解码工具 解码，再用 JSON 格式化工具查看——这在调试 OAuth、JWT 等场景时特别常见。
本系列其他文章：
