泛型在Go框架中是需谨慎权衡的工程决策，须卡准时机、选对约束、避开反射陷阱；handler入参需comparable约束，结构体字段含map/slice/func时不满足该约束，Struct tag验证无法穿透泛型字段，泛型工具函数应避免过度抽象。
泛型在Go框架中不是“加了就变强”的装饰品，而是要卡准时机、选对约束、避开反射陷阱的工程决策。
泛型 handler 入参必须带 comparable 约束
很多框架（如 Fuego、Echo 的泛型中间件）要求 handler 函数的泛型参数能参与比较，否则 JSON 解析或路由匹配阶段会卡住。错误常表现为：cannot use *T as *struct{} in argument to json.Unmarshal 或绑定时 panic。
- 写法必须是
func handler[T comparable](c Context)，不能用[T any] -
comparable覆盖 bool、数值、string、指针、channel、数组、结构体（字段全 comparable） - 如果结构体字段含 map/slice/func，它就不满足
comparable，得拆成两层：外层用comparable，内层字段手动校验
PageRes[T any] 里 dive 校验不生效
Struct tag 验证（如 validate:"dive"）无法穿透泛型字段，因为反射在编译期看不到 T 的具体结构。这不是 bug，是泛型擦除后的必然限制。
- 显式实例化更可靠：
PageRes[User]而非PageRes[T any] - 若必须泛型，验证逻辑要提前：在
Bind后对Data字段单独调validator.Validate(data) - 别在 handler 里二次调
validator.Struct—— 框架已做一次，重复触发会导致双份错误响应
泛型工具函数别堆在 pkg/util 里
团队常见误区：为“看起来通用”而提前泛型化，结果 17 个 SafeUnmarshal[T any] 只有 2 个被调用。泛型成本藏在编译期：约束越宽，实例化越多，go build -gcflags="-m=2" 会显示大量重复代码生成。
立即学习“go语言免费学习笔记（深入）”；
- 高频小对象（HTTP query、DB scan）优先用具体 struct：
type UserQuery struct { ID int64 `query:"id"` } - 跨模块复用才值得泛型化，且必须带业务约束，比如
Response[T User | Admin]，而非裸[T any] - 检查是否内联失败：泛型函数没被内联，往往是因为约束太宽或嵌套太深
泛型真正的复杂点不在语法，而在判断“这个类型边界是不是真会被多个模块同时踩中”。写之前先问一句：这个泛型，三个月后还会不会有人改它？
