Engineering note
我做了一个 JSON 工作台:14 个功能,全部在浏览器本地跑
接口返回一个压缩成一行的 JSON,几万字符挤在一起,要找其中一个字段,只能横向滚。这种事干多了就会想,为什么不自己做个顺手的。
最早这个工具只有格式化一个功能。后来用着用着觉得不够,又加了校验、修复、转代码,一路加到现在的 14 个。这篇把现在的样子说清楚,也说说为什么要做成这样。
现在它能做 14 件事
按用途分一下,比一个个列清楚。
整理和检查
| 功能 | 干什么 |
|---|---|
| JSON 格式化 | 美化、压缩、选缩进(2 空格 / 4 空格 / 不缩进)、读本地文件 |
| JSON 校验 | 检查语法是否合法,定位错误位置 |
| JSON 修复 | 修常见的语法错误,比如多余逗号、单引号、括号不匹配 |
查找和比对
| 功能 | 干什么 |
|---|---|
| JSONPath | 用表达式直接查询字段,不用一层层展开 |
| JSON 差异对比 | 两份数据放一起比对,看哪里变了 |
转成别的东西
| 功能 | 干什么 |
|---|---|
| JSON 转代码 | 生成 C#、TypeScript、Java 的数据结构 |
| JSON 转 TypeScript | 单独生成 TS 接口 |
| JSON 转 Go Struct | 生成带 json tag 和嵌套结构的 struct |
| JSON 转 XML | 支持属性和节点两种形式 |
| JSON 转 YAML | 转成 YAML |
| JSON 转 CSV | 转成表格数据 |
| JSON 转 Markdown 表格 | 对象数组整理成能直接粘贴进文档的表格 |
反过来生成
| 功能 | 干什么 |
|---|---|
| JSON Schema 生成器 | 从一份样例数据反推 properties 和类型 |
还有
| 功能 | 干什么 |
|---|---|
| JSON 转义与去转义 | 在 JSON 文本和字符串字面量之间来回转换 |
入口都在 json.scung.cn,顶部一排标签页,点进去就切。不用注册,也不限次数。

几个单独的页面地址也放这儿,直接进:JSON 校验、JSON 修复、JSONPath 查询、差异对比。
平时我最常用的三个场景
工具站那边已经写了每个功能怎么点,这里说点不一样的,就是我自己在什么情况下会打开它。
调试接口,先格式化再看报错
拿到一段报错的响应,我一般先格式化,看结构对不对;如果怀疑数据本身有问题,就切到校验页看错误位置。这两步经常连着做。
顺带说个经验:很多人看到 Unexpected token 就以为接口挂了,实际八成是自己这边的数据有问题,多余一个逗号是最常见的。修复页能直接处理这类。
改配置,格式化 → 改 → 压缩
package.json、各种应用配置,改之前先格式化,改完再压缩回一行。缩进选 2 个空格还是 4 个,看项目本身的规范,别自作主张。
对接字段,让工具先生成一版
对方甩过来一份 JSON 要你建模型,手敲十几个字段纯属浪费时间。转代码页生成一版 C# 或者 TypeScript,再按项目命名规范改改就行。嵌套深的用 Go Struct 那个页,它连 json tag 都带上了。
如果要写接口文档或者校验规则,Schema 生成器能从样例反推一份初稿,比从零写快。
为什么坚持让它在本地跑
这一点我做得比较死:所有解析和转换都在浏览器里执行,JSON 内容不上传服务器。
工具站每个页面底部都挂着这句提示,不是装饰。我知道很多人拿它格式化的是公司接口的真实返回,里面有 token、有手机号、有内部字段名。这种东西从我这儿过一遍服务器,风险就落在你身上了,不值当。
代价也有。本地做意味着大文件会吃浏览器的内存,超大的 JSON 处理起来不如服务端方案稳。我接受这个代价,因为这类工具最值钱的就是"敢把真实数据粘进去"。
统计我留了,但只记按钮被点了多少次,不记你粘了什么。
做这个工具时的几个判断
为什么不做登录
想了,没做。一个格式化工具要你注册,图什么呢。没有账号体系就没有数据要存,也就不用解释这些数据去哪了,省掉一整类麻烦。
为什么会加"修复"功能
一开始我觉得格式化就够了。后来发现真实场景里,大家粘进来的经常不是合法 JSON,是从日志里抠出来的、手改过的、被某个编辑器加了 BOM 的。这时候校验只会告诉你"错了",不告诉你怎么改。
校验和修复是两件事,前者是判断,后者是帮忙。
为什么做 14 个而不是把一个做深
一开始我也想做一个大而全的单页。用过一阵发现,功能堆在一个页面上,找东西反而慢。
拆成独立页面之后有几个好处:每个页面只管一件事,进去不用找;想加新功能不影响别的;再就是搜索上,每个页面能各自对应一个长尾词(比如 JSON 转 Go Struct),比一个大杂烩页面好得多。
同样的思路也用在我做的别的小工具上,比如 GUID 生成器,就一个功能,进去点一下完事。
常见问题
Q:多大的 JSON 能处理?
没有硬性限制,取决于你自己电脑的浏览器和内存。几 MB 以内的常规数据都没问题,几十 MB 的超大文件建议先切分。因为全在本地跑,性能上限就是你机器的上限。
Q:我的数据会被保存吗?
不会。所有处理都在浏览器里完成,页面不会上传 JSON 内容,也不会写进任何数据库。关掉页面就没了。
Q:JSON 修复会不会改坏我的数据?
修复针对的是语法层面的问题(多余逗号、未加引号的键名、括号不匹配这些),不会动你的字段值。修完之后建议自己扫一眼,尤其是字段多的时候。
Q:转代码支持哪些语言?
C#、TypeScript、Java 走转代码页;Go Struct 和 TypeScript 接口有各自的独立页面,生成的东西更细一些。
Q:JSONPath 怎么用?
在 JSONPath 页粘贴数据,写表达式查询字段。适合从很深的嵌套结构里取值,省得一层层点开。
Q:手机上能用吗?
能打开,但这类工具本来就是给电脑用的。手机上屏幕窄,看嵌套结构很受罪。
最后
这个工具从只有格式化一个功能,到现在的 14 个,全是自己用出来的需求。每加一个功能,都是因为某天我又被某个具体问题卡住了加的。
它不解决什么大问题,就是让你在处理 JSON 的时候少烦一点。如果你也经常被压缩成一行的 JSON 折腾,希望它能帮上忙。
工具入口:json.scung.cn
有想要的功能或者有 bug,微信 wx_light_code,或者从关于页面找我。
继续阅读
沿「独立产品开发日志」继续。
围绕 LightCode 与 Winsaa,公开需求、架构、迭代与复盘,不用结果倒推过程。