TypeScript 在中后台项目中的边界建模

中后台项目最容易遇到的问题不是“没有类型”，而是类型很多却没有边界。提示有了，约束不强，最后还是要靠人脑记规则。

1. 先区分领域类型和展示类型

我现在很少直接把接口返回类型一路传到页面组件里。更常见的做法是先定义领域模型，再针对表格、表单、图表分别映射出展示层类型。

这样做的好处是 API 变动时影响范围更小。

2. 表单类型不应该等同于提交 payload

表单状态里经常包含临时字段、UI 辅助值、格式化后的字符串和校验错误信息。如果直接把它当 payload，就会很快出现类型混杂。

更推荐的方式是：

• FormState 负责页面编辑态
• SubmitPayload 负责提交协议
• DomainModel 负责业务语义

3. 权限结构要提前显式化

很多后台系统一开始只用字符串判断权限，后面角色一多，判断逻辑就散在各处。只要项目确定会长期维护，权限结构就值得提前抽象成明确类型。

type Role = "boss" | "sales" | "coach";

type PermissionMap = {
  canViewDashboard: boolean;
  canEditLeads: boolean;
  canManageStaff: boolean;
};

4. 查询参数和页面状态不要混在一起

分页、筛选、标签页切换这些东西，表面上都属于“状态”，但语义上并不相同。查询参数负责可分享和可恢复，局部状态负责即时交互，把它们混用后很难维护。

5. 组件 Props 要尽量收窄

如果一个组件直接接收完整实体对象，短期会感觉方便，长期则会让依赖蔓延。组件更适合只拿它真正需要的字段。

6. 类型命名不要只追求简短

中后台代码维护周期长，ItemData、InfoType 这种名字很快就失去意义。我更偏向于用能直接体现边界的名字，比如 LeadTableRow、StaffFormPayload、DashboardMetric.

7. 类型系统的目标不是“更聪明”，而是“更稳定”

我现在已经不太追求特别炫的泛型技巧。对业务项目来说，可读性、边界清晰和升级成本通常比“类型写得非常高级”更重要。

总结

TypeScript 在中后台项目里的价值，不是让编辑器更热闹，而是让领域边界更稳定。只要把表单、接口、权限和组件依赖这几层分开，后续维护会轻松很多。