一份 JSON 生成七种语言的类型定义

后端给了一段示例响应，前端要写 interface，Go 服务要写 struct，Java 要建 POJO，Python 要建 Pydantic 模型……同一份结构手敲七遍，既慢又容易漏字段。把示例 JSON 粘进生成器，七种语言一次出稿，剩下只做少量人工收尾。

一、七种语言各有哪些「方言规则」

语言	产物	关键映射规则
TypeScript	interface / type	嵌套对象拆成子接口，数组转 T[]，可空与可选字段区分
Go	struct + json tag	字段名转 PascalCase，数字分 int64/float64，缺失字段补 omitempty
Java	POJO 类	嵌套对象拆独立类，数组转 List，可选 @JsonProperty 注解
C#	属性类	[JsonPropertyName] 注解，支持可空引用类型
Python	Pydantic BaseModel	自动引入 List/Optional，可选字段给默认值，非标准字段名用 Field(alias)
Rust	Serde struct	字段转 snake_case 并补 serde(rename)，数组转 Vec，可选转 Option
Kotlin	data class	@Serializable / @SerialName 支持，可空字段给默认值

可以看出生成器真正省的不是打字，而是各语言命名习惯与序列化注解——这些恰恰是手写最容易漏、编译或反序列化时才暴露的部分。

二、让生成结果更准的三个前置动作

1. 给一份「饱满」的样例：字段尽量齐全、值不为空。全是 null 的字段只能推断成可空类型，等于把判断又推回给你；
2. 合并多条响应：分页、成功、失败几种结构差异大时，分别生成再合并，或先人工决定用联合类型；
3. 统一数字口径：JSON 只有 number，整数与浮点要靠你定。金额、ID 这类字段生成后要复核（Go 的 int64、Java 的 Long 是否符合业务）。

三、生成之后必做的四项检查

• 必填与可选：单条样例判断不出哪些字段一定存在，按接口文档收紧（TS 的 ?、Rust 的 Option、Pydantic 的默认值）；
• 特殊字段名：带空格、短横线、数字开头或语言保留字的字段，靠 alias / rename / 注解兜底，生成结果里已给出，但要确认序列化两端一致；
• 日期与时间：字符串形式的 ISO 时间通常要换成语言原生时间类型；
• 枚举与范围：状态字段建议改成枚举，数值范围加校验，别停留在 string / number。

四、常见问题

问：生成的代码能直接上生产吗？
建议当作高质量草稿。结构映射是准确的，但业务约束（必填、枚举、精度、时间类型）需要人工补一遍。先生成再收紧，比从零手写快得多。

问：示例 JSON 里含真实数据，安全吗？
七个工具都在浏览器本地解析，JSON 不上传服务器。但含用户信息的响应仍建议脱敏后再粘贴。

问：数组里元素类型不一致怎么办？
生成器会给出联合类型或宽泛类型，多数情况下说明接口本身该收敛了——先和后端确认，再用联合类型兜底。

五、推荐顺序

1. 先要一份字段齐全的真实响应；
2. 按项目技术栈选对应生成器，导出源码文件；
3. 按接口文档收紧必填项、枚举与时间类型；
4. 拿生成结果跑一次真实反序列化，确认注解与别名没写反。

类型定义是重复劳动，交给工具；业务语义是判断活，留给自己。这个分工定下来，多语言项目的接口对接会清爽很多。