直接回答：Go 泛型最甜的场景是与类型参数同构的容器和算法：泛型切片工具（Map/Filter/Reduce/Contains）、泛型数据结构（Set、LRU、堆）、类型安全的封装（Result[T]、可选值）。官方明确提醒的反模式：用泛型替代接口做抽象（比如泛型化 io.Reader 式的行为抽象）、把简单的接口断言改写成泛型、为了用而用导致 API 阅读成本上升。经验法则：先写具体类型版本，出现第三次重复且逻辑完全一致时，才抽象成泛型。
展开解析：理解约束表达：类型集合语法 constraints.Ordered 这类用 ~（底层类型）和 |（并集）描述可比、可排序等能力，comparable 对应 map key 需求。几个 Go 特有的坑：泛型不做协变逆变，[]Apple 不能当 []Fruit 用（接口也一样）；类型参数在运行期以 GCShape 单态化，二进制膨胀通常可控但别在热循环里无意识生成大量实例；方法不能新增类型参数（只有函数和类型能参数化），想给泛型类型加新方法需用原类型的参数。工程信号：如果你的泛型函数体内全是类型断言和反射，说明方向错了——泛型消除的是编译期重复，不是运行期分发的替代品。
追问方向：~int 与 int 在约束中的区别？为什么方法不能有独立类型参数？泛型与接口的边界案例？
（约 450 字）