A. 痛点描述（Problem）#
JSON 相关工作之所以烦，是因为它横跨很多环节：
- 调试接口：需要快速校验、格式化、定位字段
- 做数据交付：需要 JSON → CSV 给业务同学
- 做配置对接：需要 JSON → YAML/XML
- 做工程落地：需要从 JSON 生成 TS/Go/Java 等实体类型，避免手写
很多工具只解决一个点，而你真正需要的是“同一个地方把一整套链路做完”。
👉 这就是 JSON 工作台的定位：一站式把 JSON 从“不可用”变成“可交付”。
工具入口：
立即使用工具
B. 核心原理（Deep Dive）——为什么建议“先校验/格式化，再做转换/代码生成”？#
因为所有转换/生成都依赖一个前提：输入必须是合法 JSON。
你可以对着报错猜很久；也可以让校验器给你行列号，让树预览帮你看层级，让复制路径帮你标注问题点。
正确顺序会让效率产生数量级差异：
- 校验 → 2) 格式化 → 3) 浏览/搜索 → 4) 编码/转义处理 → 5) 转换/代码生成
C. 场景对照：你要做什么，就点哪个功能？#
工具入口：
立即使用工具
场景 1：接口返回解析失败（定位语法问题）#
- 用：编辑器校验 + 格式化
- 结果：直接拿到错误行列号；格式化后结构更清晰
场景 2：JSON 很大，找字段/找值很痛苦#
- 用：右侧树预览 + 搜索 key/value
- 结果：快速定位字段层级；可复制路径
$.a.b[0].c
场景 3：把 JSON 放进字符串字段（需要转义）#
- 用：编码 → 斜杠转义
- 结果：把
"、\n、\t、\等处理成可安全嵌入的字符串形式
场景 4：拿到“被转义过的 JSON 字符串”，要还原成真正 JSON#
- 用：编码 → 去斜杠转义 → 再格式化
- 结果：把字符串还原成可再次解析的 JSON 对象结构
场景 5：交付 CSV 给业务/分析（表格化）#
- 用：转换 → JSON → CSV
- 前提：JSON 数组（对象数组最佳）
- 选项：分隔符、是否展开嵌套字段（拍平字段成列）
场景 6：对接配置或老系统（YAML/XML）#
- 用：转换 → JSON → YAML / XML
- 选项：YAML 缩进；XML 根节点名称
场景 7：写代码不想手搓类型（最省力）#
- 用：转换 → JSON → 代码实体
- 支持：TypeScript / Go / Java / C# / Python
- 建议：把根类型名设成你项目的命名风格（例如
UserDTO、OrderItem）
D. 最短操作路径（3 步走）#
- 粘贴或上传 JSON → 先格式化
- 树预览搜索关键字段 → 复制路径用于沟通/排错
- 按交付目标选择转换（CSV/YAML/XML/GET 参数/代码实体）→ 复制或下载
E. 常见问题（FAQ）#
1）为什么转换 CSV 提示要 JSON 数组？#
CSV 本质是“多行记录”，自然对应对象数组。如果是单个对象，建议先包一层数组或选择别的转换（如 YAML/Query）。
2）为什么我的 JSON 校验失败，但我肉眼看不出来？#
高频是不可见字符、非法转义、尾逗号。用行列号定位比猜更快。
3）代码实体生成出来后还能用吗？需要手改吗？#
生成的是结构雏形，能显著减少手写负担；你通常只需要按项目约定补少量注解、命名或可选性策略。
工具推荐#
- JSON 工作台：立即使用工具
- JSON 树视图（独立入口）：立即使用：JSON 树视图
- JSON 压缩（独立入口）：立即使用：JSON 压缩