先把 JSON 当作样本，不要当成完整接口契约
前端联调时，拿到一段接口返回的 JSON，先生成一个 TypeScript 类型，能比手写每个嵌套字段更快进入开发。但一份成功响应只说明“这次返回了什么”，并不能说明字段永远存在、数组永远不为空，或 null 在业务上代表什么。
把样本粘贴到 JSON 转 TypeScript Interface 工具 后，可以选择生成 interface 或 type，并设置根类型名称。输出适合作为初始定义；提交代码前，还要对照接口文档、后端约定或多份真实响应，把不确定的地方明确写出来。
用三类样本检查字段缺失、空数组和 null
假设订单接口的一次响应包含 customer、items 和 coupon。如果只用这一次样本生成类型，coupon 可能被推断为 string，但另一个订单可能没有优惠券，后端也许会返回 null，甚至完全省略该字段。两种情况在 TypeScript 中应分别考虑为可选字段或包含 null 的联合类型，不能只看一次样本。
数组也一样。工具遇到空数组时只能得到有限线索，无法从 [] 知道元素结构；遇到有内容的数组时，会根据当前元素推断类型。请准备至少一份“正常有数据”的样本和一份“没有数据”的样本，比较输出差异。对复杂 JSON，可先用 JSON 格式化工具 展开层级，再找出真正需要覆盖的分支。
生成后先处理真正的可选性与业务枚举
生成结果里的字段名称和基本数据类型，能减少重复输入，但业务语义仍要人工补齐。例如状态字段从样本中可能只是 string，而接口文档实际限定为 pending、paid、cancelled；这时应改成联合字面量类型。金额、时间戳、ISO 日期字符串和 ID 也常被推断为 number 或 string，但它们的单位、时区和格式不应靠猜测。
联调用 mock 时，不要为了让页面通过编译而把所有字段都设成必填。先标出未确认的字段，再让 mock 分别覆盖字段缺失、空值和边界数组。这样组件在真实接口出现少量差异时，比较不容易直接报错或显示错误内容。
用差异比较确认接口改动，而不是只看生成结果
后端更新接口后，重新生成类型可以帮助发现结构变化，但不应直接覆盖原有定义。将新旧 JSON 或新旧类型放进 文本差异比较工具 查看，重点检查新增字段、删除字段、层级变化和 null 的变化。然后再判断这是否是兼容改动，以及前端是否需要迁移。
在代码评审中，也把样本来源写清楚：是接口文档示例、测试环境响应，还是脱敏后的生产样本。样本可能包含敏感信息，复制前要删除令牌、邮箱、手机号和客户数据。类型生成工具只能转换你粘贴的结构，不能验证权限、接口版本或数据是否符合业务规则。
生成类型不能替代接口文档和运行时校验
TypeScript 类型只在开发阶段提供检查，运行时收到的 JSON 仍可能不符合预期。对关键流程，可在边界处加入适合项目的运行时校验，并把失败情况显示为可诊断的错误，而不是假设所有响应都和样本一致。
如果接口尚未稳定，优先与后端确认版本、字段含义和兼容策略。生成工具可以节省开始编写类型的时间，却不能自动发现遗漏的分支；样本覆盖范围和实际响应测试仍是最后的依据。
常见问题
JSON 转 TypeScript 后可以直接提交吗？
可以作为起点，但请先核对接口文档和多份响应。特别是可选字段、空值、数组元素和状态值，通常需要人工调整。
空数组为什么无法推断出元素字段？
空数组没有元素可供观察，工具无法知道其中对象应该有哪些字段。请补充包含代表性元素的样本。
interface 和 type 应该选哪个？
两者都可用于描述结构。若项目已有约定就沿用；没有约定时，选择团队更容易维护的写法，并保持同一模块一致。
字段有时不存在、有时是 null，怎么写？
先确认后端语义。完全省略通常需要可选字段，明确返回空值则需要包含 null；两种情况也可能同时存在。
这个工具会验证接口返回是否正确吗？
不会。它根据输入 JSON 生成初始类型，不能连接接口、验证权限或确认业务约束。请结合文档、测试和运行时处理。