泛型参数应按职责分层：k为标识维度（如id类型），v为值维度（如业务实体），c为行为或上下文约束（如状态枚举、区域策略），各参数须有明确语义边界与类型约束，避免嵌套推导和单字母命名。
多个泛型参数在复杂业务对象中不是堆砌类型，而是分层表达职责——K 表示标识维度（如 ID 类型），V 表示值维度（如业务实体），T 表示行为约束（如状态枚举或校验规则）。关键在于每个参数必须有明确语义边界，避免“一个泛型包打天下”。
按角色划分泛型参数，不按数量堆叠
业务对象常需同时承载身份、内容、上下文三类信息。例如订单服务中：
-
K：唯一标识类型（
string或number，对应 orderNo 或 orderId） -
V：主数据结构（
OrderDetail、RefundInfo等具体 DTO） -
C：上下文约束（
Locale、Currency或PermissionScope，用于运行时策略控制）
写法示例（TypeScript）：
class BusinessService<k v c> {
constructor(private idKey: K, private data: V, private context: C) {}
// 方法内部可基于 C 做权限分支，基于 K 做缓存键生成，基于 V 做序列化
}</k>
用泛型约束替代宽泛 any，而非放任类型自由
多个泛型若无约束，等于放弃类型安全。应在声明时绑定最小可行契约：
- 对标识类泛型（如 K），加
extends string | number或更细粒度的extends `${string}-id` - 对数据类泛型（如 V），要求实现
Validatable接口或含id和updatedAt字段 - 对上下文泛型（如 C），限定为枚举字面量联合类型，如
type Context = 'CN' | 'US' | 'EU'
Java 示例：
public class OrderProcessor<id extends charsequence data hasid validatable region enum>> { ... }</id>
避免跨层耦合：泛型之间不相互推导
常见错误是让一个泛型依赖另一个泛型的字段类型（如 V[K]），这会把简单映射变成类型地狱。应保持各泛型正交：
- 不写
<k extends keyof v></k>这类嵌套约束，除非真需要键值联动（如工具函数） - 若需关联，提取为独立类型参数，例如
<k v fieldkey extends keyof></k>，把“关联动作”显式暴露给调用方 - 业务对象构造时，三个泛型应能各自独立传入，不强制要求某两个来自同一对象
命名即文档：用业务词代替单字母
在团队协作或长期维护场景下，<t u r></t> 几乎无法传达意图。推荐：
- 标识类：用
IdType、KeyFormat、Identity - 数据类：用
Payload、Entity、Dto - 策略类：用
Policy、Scope、Mode
示例（Go）：
func ProcessOrder[IdType ~string, Payload any, Policy PolicyType](id IdType, p Payload, policy Policy) error { ... }
