JSON 转 TypeScript:转换差异、边界与常见坑

在线 JSON 转 TypeScript:生成 interface 并推断可选性,对联合类型、嵌套数组与需要手动收窄的字段明确标注,便于前端类型与后端接口对齐,减少联调返工。

生成 interface 的准确度取决于样本的代表性:全样本都出现的字段才会被标为必填,空数组推不出元素类型,字面量联合与可选属性都需要人工收口。它擅长省去体力活,不擅长替你做类型设计。

两种格式的差异对照

维度JSONTypeScript 类型
类型强度无类型,运行时才有值编译期检查,IDE 可提示
字段可选性字段可能不出现用 ? 或 | undefined 显式表达
字面量联合无此概念可写 "a" | "b" 限定取值集合
数字与字符串都是 number/string可细分为字面量、模板字符串类型
命名无类型名需要人工起语义化名字(工具只能给 Root/Item)
可辨识联合异构对象混在同一数组用判别属性构建 discriminated union
运行时校验无类型在编译后被擦除,运行时仍需校验
代码体积数据本身类型声明不产生运行时代码

边界条件

  • 字段在全样本都出现才能标记为必填;只要有一个样本缺失就变成可选,接口契约会偏宽松。
  • JSON 的 null 需要显式写成 | null,否则严格模式下赋值 null 会报错。
  • 日期是字符串,类型系统无法区分"普通字符串"和"ISO 日期",需要手工用模板字符串类型加约束。
  • 超过 2^53 的整数在 JS 里失真,类型写成 number 会掩盖问题,建议该字段改成 string。

常见坑

  • 把生成结果当作接口契约直接提交,可选性偏宽松导致空指针跑到线上。
  • interface 名全是 Root/Item,半年后没人知道哪个类型对应哪个接口。
  • 大整数编号写成 number,前端解析即失真且类型检查不会报错。
  • 依赖类型做运行时校验——类型在编译后消失,非法数据照样进来。

相关工具

常见问题

怎么把 TypeScript 再转回 JSON?

使用同工具的交换方向功能,或本站对应的「TypeScript 转 JSON」页面,两者都本地运行、数据不上传,可完成往返转换与校验。

JSON 和 TypeScript 哪个更适合人类阅读?

这取决于场景:TypeScript 通常更偏向程序解析与接口传输式的可读形态,而 JSON 更利于程序解析与接口传输式的程序消费;需要人工编辑时优先选可读性更高的那一侧。

为什么生成的 interface 名字都叫 Root?

因为 JSON 本身不携带类型名——顶层对象没有名字,工具只能用 Root、Item、Data 之类的占位名。要贴近业务语义,生成后手动重命名 interface(并用 IDE 的重命名重构一次性改全),或者先用 JSON Schema 给每层命名再生成。

嵌套数组会生成什么类型?

T[] 或 Array<T>,元素类型取数组第一个元素。空数组会退化成 any[] 或 never[],需要手工指定;元素异构时只反映第一个元素的形状,其余元素在类型检查里会报错。