JSON 生成代码定义
根据示例 JSON 生成 TS / Go / Java / C# / PHP 类型定义
从 JSON 生成类型定义：能省多少事，哪里必须人工改
它做的是"从样例推断结构"
生成器读一份示例 JSON，按值推断出类型，输出目标语言的类型定义。本质是归纳：从有限的样本里猜出通用的结构。这个过程的可靠性完全取决于样本的代表性，所以有一类问题是它原理上无法解决的——必须人工修正。
五处必须人工确认的地方
| JSON 现象 | 生成结果的常见问题 | 怎么改 |
|---|---|---|
"count": 0 | 推断成数字，看不出该字段是否可能为 null | 按接口文档补可空标记 |
"tags": [] | 空数组无法推断元素类型，多会生成 any[] / unknown[] / interface{} | 手工指定元素类型，或换一份含元素的样本 |
"price": 9.9 | 浮点与整型无法区分；Java/C# 里 int 与 long 也分不出 | 按业务范围选定具体数值类型 |
"createdAt": "2026-01-15T08:00:00Z" | 生成字符串类型，不会变成日期类型 | 按语言惯例决定转成日期对象还是保留字符串 |
| 样例中缺失的字段 | 生成结果里完全没有这个字段 | 补上——这是最常见也最危险的漏项 |
第三行值得特别说明：很多 JSON 序列化实现会把 int64 输出成数字，但 JavaScript 只能精确表示到 253-1，且 Java 的 int 只有 32 位。金额、ID 这类字段如果类型选窄了，会在生产环境的某个大值上突然溢出或丢精度。不要用样例的数值范围来决定类型宽度。
命名与结构随语言变化
JSON 的键惯例上是 camelCase，各语言的目标风格不同，生成器会转换：
| 语言 | 类型名惯例 | 字段名惯例 | 常见补充 |
|---|---|---|---|
| TypeScript | PascalCase interface | 保持 camelCase | 可选字段用 ?，联合类型用 | |
| Go | PascalCase struct | 导出需首字母大写，故转为 PascalCase | 需要 JSON tag 才能对回原键名 |
| Java | PascalCase class | 保持 camelCase | Lombok 注解、@JsonProperty 映射 |
| C# | PascalCase class | 转为 PascalCase | 需 [JsonPropertyName] 才能对回原键名 |
| PHP | PascalCase class | 保持 camelCase | 可加类型声明与默认值 |
Go 和 C# 这两行是实际使用时最容易忘的：改了大写首字母之后，如果没有显式的字段映射标注，序列化出来的键名会和接口约定不一致，表现为"字段全是零值"。生成后务必检查这些标注是否存在。
嵌套结构与类型复用
同一结构的对象在样例里出现多次时，生成器有两种策略：每个位置生成一份（重复定义，简单但代码膨胀），或者抽取成一个共享类型（需要判断两个结构是否"确实同一个实体"）。
自动合并有风险：两个结构恰好字段相同但业务含义不同（比如"用户地址"和"收货地址"），合并后任何一方新增字段都会影响另一方。所以生成结果里的类型合并建议要人工复核，不要照单全收。
数组与联合类型
样例里数组元素类型不一致时，生成器要么输出联合类型（TypeScript 的 (string | number)[]），要么退化成宽松类型。如果出现联合类型，通常意味着接口设计有问题（同一字段承载两种类型），值得回头确认后端意图，而不是在类型定义里容忍它。
适合用与不适合用
- 适合：对接第三方接口时的快速起步、把调试抓到的响应转成能用类型、为已有 JSON 数据写一次性处理脚本、比较两份接口响应的结构差异。
- 不适合：作为契约的唯一来源。正确的契约定义来自 OpenAPI/JSON Schema/Proto 这类带语义的规范，类型定义应该从规范生成，而不是从一次抓包反推。样例里没有的字段、可空性、取值范围，都是抓包看不出来的。
- 注意：超大或嵌套很深的 JSON 会生成极其冗长的结果，建议先用工具裁剪出需要的子树再生成。
生成过程在浏览器本地完成，接口响应不会被上传——涉及内部接口结构时这一点很重要。
常见问题
类型推断准吗？
基于你给的示例。数组仅看第一个元素推断；若示例里该字段是 null，会退化为通用类型（如 Object / interface{}），建议补全示例再生成。
能生成构造函数或校验注解吗？
本工具只生成纯类型/类骨架，不含业务逻辑。需要注解或方法时，可在此基础上自行补充。