告别 AnyScript：TypeScript 高级类型在业务组件中的实战指南
在日常的复杂前端业务开发中，开发者为了赶进度常常会妥协，将 TypeScript 写成了“AnyScript”。本文将结合实际的组件封装场景，分享如何利用 TypeScript 的高级类型，提升项目的可维护性和开发体验。
1. 泛型与继承的结合
我们在封装通用 Table 组件或者 Select 下拉框时，最常见的痛点是不知道业务接入方具体会传入什么结构的数据。依靠强行 any 或 Record<string, unknown> 显然不是好的解决方式：
// 错误示例：使用了 any 丢失了类型推导
interface TableProps {
data: any[];
columns: any[];
}
更好的方式是使用 泛型 (Generics) 并配合 extends 关键字增加约束：
typescript
// 建议的做法
interface BaseRecord {
id: string | number;
}
interface TableProps<T extends BaseRecord> {
data: T[];
onRowClick?: (record: T) => void;
}
通过这种方式，onRowClick 在被回调时，能够精准推导出当前行的字段属性，大大减小了引发运行时 undefined 报错的风险。
2. 巧用 Utility Types
在封装表单更新接口时，如果你要将一个原有的 User 类型转换成“可部分更新”的高级类型，千万不要重新写一遍所有的字段。
使用 TS 内置的工具类型 Partial<T>、Pick<T, K> 搭配起来，可以极简地衍生出业务所需的组合体：
typescript
interface UserInfo {
id: string;
username: string;
email: string;
role: 'admin' | 'user';
createdAt: Date;
}
// 仅允许更新邮箱与角色，且字段均为可选
type UpdateUserPayload = Partial<Pick<UserInfo, 'email' | 'role'>>;
3. 结语
使用 TypeScript 的本质不应当只是为了“通过编译”，而是利用类型去表达设计意图和业务约束。通过恰当的高级类型工具应用，我们能够把很多潜在的业务逻辑错误提前扼杀在编译阶段，写出更加稳定、优雅的底层组件。
下次在写下 any 之前，不妨思考一下是否可以用泛型或工具类型解决问题。希望以上两点分享能为你在项目实践中带来一些小启发！
