go 1.18泛型不是语法糖，它使编译器能在构建阶段捕获类型错误，避免interface{}导致的运行时panic；泛型将类型信息前移至编译期，消除类型断言失败风险，生成无类型擦除开销的二进制。
Go 1.18 泛型不是语法糖，它能直接让编译器在构建阶段捕获类型错误，彻底规避 interface{} 带来的运行时 panic 风险。
泛型函数为什么能替代 interface{} 类型断言
用 interface{} 写通用逻辑时，你得靠运行时类型断言（v.(MyType)）来“猜”值的类型；一旦断言失败，程序就 panic。泛型把类型信息提前到编译期：编译器知道 T 具体是什么，也清楚它是否支持 .String()、+ 或其他操作。
- 类型断言失败是运行时错误，无法被 IDE 提示或单元测试覆盖
- 泛型函数调用时，如果传入类型不满足约束，编译直接报错，比如
cannot use string as T in argument to LogValue - 生成的二进制里没有类型擦除开销，也不需要反射或接口动态调度
如何写一个真正安全的泛型 Must 函数
老式 Must 常用 func Must(v interface{}, err error)，返回 v 时还得手动断言；泛型版可完全保留原始类型，零运行时成本。
func Must[T any](obj T, err error) T {
if err != nil {
panic(err)
}
return obj
}
- 调用
Must(os.Open("x.txt"))时，返回值类型就是*os.File，不是interface{} - 不能对任意
T做运算（比如+），除非加约束：[T Number]，否则编译会拒绝Must(1, nil) + Must(2, nil) - 注意：
T any不代表“可以做任何事”，只代表“可以是任何类型”，具体操作仍受约束限制
泛型约束没写好，反而比 interface{} 更难 debug
泛型出错时，错误信息往往嵌套深、提示模糊，比如 cannot use []string as []T，其实只是因为你忘了约束里没包含 string。
- 常见错误：定义
type Ordered interface{ ~int | ~float64 }，却传入[]string—— 编译器不会自动推导string满足Ordered，因为没在约束里声明 - 别用
any当万能兜底；需要行为契约时，明确定义接口，比如type Stringer interface{ String() string } - 嵌套泛型（如
func Map[T, U any](s []T, f func(T) U) []U）容易触发类型推导失败，建议在复杂调用处显式标注类型参数：Map[string, int](strs, strLen)
interface{} 还有它的位置，但不该是第一选择
泛型不是要消灭 interface{}，而是帮你判断：什么时候该让它退场。
- 日志、序列化、反射场景仍需
interface{}—— 它们本就要处理未知类型 - 数据库 ORM 的通用查询层（如
Find(&users)）若用泛型，就得为每种 struct 写专用方法，反而增加维护负担 - 真正该替换的是那些“本就知道类型，却硬塞进
interface{}再断言出来”的地方：比如配置解析、HTTP handler 中的参数提取、工具函数
泛型的安全性不来自语法本身，而来自你是否愿意花时间定义清晰的约束——这一步跳过，interface{} 的坑只是换了个地方等你。
