为什么我们把类型当成需求的一部分

接手一个项目时，最先看的不是页面好不好看，而是数据长什么样。字段含义含糊、可选和必填随意、金额用字符串随手传递，这些问题在演示阶段看不出来，等到要加一个筛选条件或对账导出时，才发现每处代码都有自己的理解。

所以我们习惯在动手写界面前，先把类型定义固定下来。它既是对客户的确认，也是对后来接手者的说明：这个字段一定存在，那个字段可能为空，金额以分为单位存储。

类型先行的三个实际收益

• 把「金额精度」「时区」「是否可空」这类容易被忽略的口径写死在结构里，减少后期返工。
• 页面与接口共用同一份类型，字段改名时编译期就能发现问题，而不是等用户投诉。
• 交接时不需要逐行解释，类型文件本身就是一份可以查阅的字段说明。

下面是一段被简化过的订单类型，实际项目里还会带上状态机与操作记录：

export interface Order {
  id: string;
  customerId: string;
  amountCents: number;
  status: "draft" | "confirmed" | "shipped" | "closed";
  createdAt: string;
  shippedAt: string | null;
}

如果一个字段的口径说不清，那多半不是技术问题，而是业务规则还没对齐。

类型不是越多越好

另一种常见问题是为了抽象而抽象：一层套一层的泛型，看起来高级，实际改一个字段要翻三四个文件。我们更倾向于把类型收敛在业务边界上，接口出参与页面数据各有一份明确的结构，中间不做无意义的映射。

判断标准很简单：新增一个业务字段时，需要改动的位置是否集中。如果需要改动的地方超过两处，说明这一层的抽象没有带来收益。

写在最后

类型定义是交付物的一部分，和接口文档、部署说明一起交出去。客户未必会读，但下一个维护系统的人一定需要它。