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