interface{ ~int | ~string }合法是因为~前缀表示底层类型兼容，而interface{ int | string }非法因int和string底层不同；Go不支持容器类型隐式转换，类型推断失败需显式指定类型参数。
Go 的类型参数不是“泛型模板参数”，而是受接口定义的类型集合约束的实参；所谓“类型集合”，就是编译器能静态确认的一组底层兼容类型，不是运行时可变的联合类型。
为什么 interface{ ~int | ~string } 是合法的，而 interface{ int | string } 会报错
Go 编译器只允许在带 ~ 前缀的底层类型之间用 | 并列，表示“这些类型共享同一底层表示”。~int 指所有底层是 int 的类型（比如 type ID int），~string 同理。但 int 和 string 底层完全不同，无法共存于一个类型集合中。
-
interface{ ~int | ~int32 }❌ 报错：两者底层不同（int是平台相关，int32是固定宽度） -
interface{ ~int }✅ 允许：单个底层类型 -
interface{ ~int | ~int64 }❌ 不行：即使都是整数，底层不一致 - 想同时支持
int和int64？得写两个约束，或用更宽泛的constraints.Ordered（来自golang.org/x/exp/constraints）
map[string]T 传给 func(m map[string]io.Reader) 为什么会失败
这不是泛型问题，是 Go 类型系统对复合类型的严格判定：map[string]*bytes.Buffer 和 map[string]io.Reader 是两个完全不同的类型，哪怕 *bytes.Buffer 实现了 io.Reader。接口实现关系不传导到容器类型上。
- 错误现象：
cannot use m (type map[string]*bytes.Buffer) as type map[string]io.Reader - 根本原因：Go 不做隐式容器类型转换，避免底层数组/哈希表内存布局混淆
- 正确做法：构造时就用目标接口类型，例如
m := map[string]io.Reader{"a": &bytes.Buffer{}} - 若已有
map[string]*bytes.Buffer，需手动遍历转换：for k, v := range oldMap { newMap[k] = v }
类型参数推断失败的常见场景
编译器无法从函数调用上下文中唯一确定类型实参时，就会要求显式提供 [T]。这不是 bug，是类型安全的必要代价。
立即学习“go语言免费学习笔记（深入）”；
- 调用
min(a, b)时，若a和b类型不同（如int和int64），推断失败 - 函数返回值未被使用，且参数无足够类型线索（如
newSlice()没传元素） - 约束接口太宽，比如
interface{ ~int | ~float64 | ~string }，传"hello"仍可能歧义（~string还是其他字符串别名？） - 解决方法：显式写
min[string]("a", "b")或确保入参类型一致
最易被忽略的是：类型集合的边界由 ~ 严格限定，不是靠语义判断；而 map/slice 的类型安全不依赖泛型，它在非泛型上下文中同样严格——这点和 Rust 或 TypeScript 完全不同。
