图标系统契约设计：泛型与继承方案哪种更合理？

这确实是TypeScript类型设计里非常常见的权衡场景——两种方案最终都能实现一致的接口效果，但开发体验和长期维护成本的差异不小。我来帮你拆解下两者的优劣势，以及更适合的选择方向：

先回顾两种方案的实现 #

继承方案 #

export interface Icon { type: 'account' | 'img' | 'font-icon'; }
export interface AccountIcon extends Icon { readonly type: 'account'; value: LinkIcon<LinkIconType>; }
export interface ImgIcon extends Icon { readonly type: 'img'; value: Icon; }
export interface FontIcon extends Icon { readonly type: 'font-icon'; value: string; }

泛型方案 #

export type IconType = 'font-icon' | 'img' | 'account';
export interface FilterIcon<T extends IconType> { readonly type: T; value: T extends 'account' ? LinkIcon<LinkIconType> : T extends 'font-icon' ? string : Icon; }

两种方案的优劣势分析 #

继承方案：清晰但繁琐 #

• 优点：接口结构非常直观，每个图标类型都是独立的、语义化的接口，新人接手时能快速看懂各个图标的结构定义。
• 缺点：最大的痛点就是类型断言的冗余与风险——每次处理Icon类型的对象时，都必须手动用as AccountIcon（或其他具体类型）来断言，不仅写起来麻烦，还容易出错：如果断言的类型和实际type不匹配，编译阶段可能无法发现，会埋下运行时的隐患。另外，后续新增图标类型时，需要新增对应的继承接口，样板代码会越来越多。

泛型方案：高效但有学习成本 #

• 优点：零成本的类型推导与自动补全是最大的亮点——只要你指定了type属性，TypeScript会自动推断出value的正确类型，完全不需要手动断言，开发体验非常流畅。而且新增图标类型时，只需要扩展IconType联合类型，并调整泛型里的条件判断即可，代码更紧凑，维护成本更低。
• 缺点：接口的可读性确实弱一些，尤其是嵌套的条件类型部分，对TypeScript不太熟悉的开发者可能需要花点时间理解T extends 'account' ? ...这种逻辑。

推荐选择与优化建议 #

如果团队成员对TypeScript的条件类型和泛型有基本了解，优先选择泛型方案——它带来的开发效率提升和类型安全性是长期的收益，可读性的问题可以通过小优化来弥补：比如把复杂的条件类型抽成单独的类型别名，让接口本身更简洁：

export type IconType = 'font-icon' | 'img' | 'account';

// 把value的类型逻辑抽成单独的别名，提升可读性
export type IconValue<T extends IconType> = 
  T extends 'account' ? LinkIcon<LinkIconType> : 
  T extends 'font-icon' ? string : 
  Icon;

export interface TypedIcon<T extends IconType> { 
  readonly type: T; 
  value: IconValue<T>; 
}

如果团队里很多人是TypeScript新手，或者图标类型后续不会频繁新增，继承方案的清晰性可能更友好，但一定要注意类型断言的规范，避免因错误断言导致的bug。

内容的提问来源于stack exchange，提问作者Yarin