给自己做的 JSON 工具写了份教程

最近给 Qudo JSON 工具箱整理了一份使用教程。

之前一直在加功能、改问题，文档主要靠 README。能查到支持哪些功能，也有启动和打包的说明，但真要让第一次打开软件的人照着操作，还是少了点东西。

比如，JSONPath 页面里的数据要从哪里载入？改完编辑器里的内容，为什么查询结果还是旧的？结构折叠和树形查看器有什么区别？

这些地方，写代码的时候觉得很清楚，写教程时才发现，得认真解释一下。

不按功能列表写，拿一份数据从头做起

这次没打算把 README 再抄一遍。

我准备了一份简单的 JSON，里面只有项目名称和两个用户，带着 id、name、score、active、tags 几个字段。整份教程都围绕它操作。

先打开文件，试一次格式化和压缩，再故意删掉一个逗号，看工具怎么报错。接着把数组折叠起来，展开树节点，找到某个字段。

到了对比章节，就把一个用户的分数从 72 改成 82；讲 JSONPath 时，再查询分数不低于 90 的用户。Schema 校验也用这份数据，把分数改成 120，检查它为什么不符合“最高 100 分”的规则。

例子简单一点，读的时候就不用反复理解新的数据背景，也容易知道操作结果对不对。

截图比我想的更费时间

教程里放了实际界面的截图，包括结构折叠、错误定位、JSON 对比、查询、转换和设置页面。

原本觉得，打开软件截一下就行。做的时候才发现，能用的截图还得收拾一下。

窗口太宽，放进文档后字就小；空白太多，真正要看的地方反而不明显；查询框太窄，表达式只露出最后几个字符，截图也就失去了意义。

所以又调整了显示范围，把该展示的数据和操作结果放到一起。结构折叠那张图，我保留了收起后的行号变化，能直接看出中间的内容只是藏起来了。

有些提醒，还是应该写在操作旁边

整理过程中，我特意留下了几个容易踩到的地方。

比如，历史记录默认不保存 JSON 原文。它能记住操作，并不代表关闭一个没保存的标签后，还能把整段内容找回来。

再比如，数组排序会改变元素顺序。用户列表排一下可能没事，消息记录、执行步骤之类的数据就不能随便排。

还有 JSONC。带注释的文件可以查看，但格式化会移除注释，需要先确认。工具对 JSON Schema 的支持也有范围，看到校验结果时，警告同样要读。

这些话单独放在文档最后，可能很少有人翻到。放在对应步骤旁边，至少能在点按钮前看到。

最后整理成了十二章

前几章是日常最常用的编辑、校验、折叠和查找，后面再讲数据对比、JSONPath、格式转换、Schema、统计和测试数据生成。

教程在 GitHub 的wiki上,链接地址放文章地址的最后面，。

写完这份教程，我对工具本身也重新熟悉了一遍。有些操作，自己用了很多次，手已经知道下一步点哪里；真要写成一句别人看得懂的说明，才会去想这个入口是不是好找、提示是不是说清楚了。

教程先整理到这里。我还会继续拿这套工具处理接口响应和日志，后面功能有变化，再把对应章节一起更新。

教程地址在github 教程