JSON 转 TypeScript、Go、Java 等代码（免费，2026 指南）

为什么要把 JSON 转成代码

每次对接 API 都从同一件苦差事开始：一份 JSON 响应摆在面前，你要为它写出类型结构。手写既慢又容易出错——漏掉一个字段，编译器或运行时就会在最糟糕的时刻告诉你。而且 API 一旦演进，手工维护的模型就会和现实脱节。

转换器同时解决这两个问题：它读取你提供的真实示例，输出符合各语言习惯的类型声明——模型从第一天起就和真实负载一致，API 变更后也能随时重新生成。

好的转换器能识别什么

嵌套对象生成具名类型。user.address.city 这种结构会产出独立的 Address 类型，而不是一团难以阅读的内联定义，相同结构还会按名字复用。

数组做形状合并。真实世界的数组很乱：并非每个对象都带齐所有键。好的转换器会对数组内所有条目的键取并集，把部分条目缺失的字段标记为可选——类型如实反映 API 的真实返回。

可选与可空分开处理。「有时不出现」的键和「出现但为 null」的键不是一回事。它们在每个语言里对应不同构造（TypeScript 的 ? 与 T | null、Go 的指针与零值、Rust 的 Option<T>），生成的代码保留这一区分。

深度有上限。病态深层嵌套的 JSON 只会产出不可读的输出，因此生成到合理深度即回退为通用 Map——用完整性换可读性的有意取舍。

选择你的语言

七个转换器共用同一套类型推断引擎，同一样例在各语言输出保持一致：

• TypeScript——嵌套 interface，可选字段用 ?，可空用联合类型，严格模式友好：JSON 转 TypeScript。
• Go——带 json tag 的 struct，可空字段用指针以便反序列化表达「缺失」：JSON 转 Go struct。
• Java——带 getter/setter 的 POJO，可直接配合 Jackson 或 Gson：JSON 转 Java POJO。
• Python——带类型注解的 @dataclass：JSON 转 Python dataclass。
• Kotlin——data class，可空类型用 T?：JSON 转 Kotlin data class。
• C#——属性类，适配 System.Text.Json 或 Newtonsoft：JSON 转 C# 类。
• Rust——兼容 serde 的 struct，可空用 Option<T>：JSON 转 Rust serde struct。

三步完成转换

1. 粘贴有代表性的示例。输出再准也只取决于输入：把缺字段的条目、null、嵌套列表都放进来，别只给理想路径。

2. 给根类型命名。复制前把 Root 改成有意义的名字（User、OrderResponse）；嵌套类型会按键名自动命名。

3. 复制并复核。先看可选与可空标记——转换器和 API 最容易在这里产生分歧——再粘贴进项目。

让生成类型更干净的几个技巧

喂给转换器那些「奇怪」的样例。如果某个数组条目缺字段，就转换包含该条目的样例——否则字段会被当成必需，解析时迟早出事。

API 变了就重新生成。把生成类型当作构建产物：重建成本低，永远不要手改。

深层嵌套的负载考虑用 Map。如果 API 返回任意键的字典，生成 Record<string, T> 风格的映射，比二十个一次性的 interface 更诚实。

数据不出你的电脑。ToolkitLife 的每个转换器都在你的浏览器标签页内完成解析和生成。当 JSON 里包含客户数据、令牌或任何机密信息时，这一点很重要——根本没有可以泄露数据的服务器。