泛型不能直接用interface{}是因为会丢失类型信息，无法安全调用方法、推导类型或编译检查；其核心价值在于约束可表达、可复用、可收敛，如通过Runner接口约束Start/Stop行为。
泛型替代接口约束时，为什么不能直接用 interface{}？
因为 interface{} 会丢失类型信息，导致无法在函数内安全调用方法、做类型推导或编译期检查。泛型真正的价值是让约束可表达、可复用、可收敛——比如实现工厂模式时，你希望工厂返回的实例必须有 Start() 和 Stop() 方法，但又不想为每种类型写一遍 type MyService struct{...} + func (m MyService) Start(){...}。
正确做法是定义一个约束接口：
type Runner interface {
Start()
Stop()
}
再配合泛型函数或结构体使用：
func NewRunner[T Runner](t T) *T {
return &t
}
- 传入
http.Server（只要它实现了Start()/Stop()）会编译失败——因为它没这两个方法；必须是你自己定义的类型或显式嵌入了对应方法 - 如果想兼容已有类型（如
*sql.DB），得用组合或适配器包装，不能靠泛型“绕过”约束 - 别把约束写成
interface{~string | ~int}这类底层类型联合——这属于类型集合，不是行为契约，和设计模式意图相悖
用泛型实现策略模式：如何避免运行时 panic？
策略模式的核心是「同一接口，不同行为」。泛型能帮你把策略选择提前到编译期，而不是靠字符串或枚举查 map 导致运行时找不到策略。
立即学习“go语言免费学习笔记（深入）”；
典型错误写法：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
var strategies = map[string]interface{}{"gzip": GzipCompressor{}, "zstd": ZstdCompressor{}}
func Compress(algo string, data []byte) ([]byte, error) {
s := strategies[algo] // 这里可能为 nil
return s.(Compressor).Do(data) // 类型断言失败就 panic
}
改用泛型后，策略由类型参数决定，调用方必须显式指定：
type Compressor interface {
Do([]byte) ([]byte, error)
}
<p>func Compress[T Compressor](c T, data []byte) ([]byte, error) {
return c.Do(data)
}
- 调用时写
Compress(GzipCompressor{}, data)，编译器立刻检查GzipCompressor是否满足Compressor - 如果后续新增
BrotliCompressor，不用改Compress函数，只要它实现接口即可 - 注意：不要为了“统一入口”而把所有策略塞进一个泛型函数里再加 if/switch——那又退化成运行时分支；泛型策略应保持每个具体调用路径清晰、无隐式跳转
泛型版观察者模式中，事件类型怎么隔离？
传统观察者常把事件类型硬编码成 interface{} 或某个基类，导致监听器收到不关心的事件也得做类型判断。泛型可以按事件类型分发，让监听逻辑真正“只看自己该看的”。
关键点在于：观察者注册时绑定具体事件类型，发布时只通知匹配的监听器。
type Observer[T any] interface {
OnEvent(T)
}
<p>type EventBroker struct {
mu sync.RWMutex
handlers map[reflect.Type][]any
}</p><p>func (e <em>EventBroker) Subscribe[T any](obs Observer[T]) {
t := reflect.TypeOf((</em>T)(nil)).Elem()
e.mu.Lock()
defer e.mu.Unlock()
e.handlers[t] = append(e.handlers[t], obs)
}</p><p>func (e *EventBroker) Publish[T any](event T) {
t := reflect.TypeOf(event).Kind() == reflect.Ptr ?
reflect.TypeOf(&event).Elem() : reflect.TypeOf(event)
e.mu.RLock()
for _, h := range e.handlers[t] {
h.(Observer[T]).OnEvent(event)
}
e.mu.RUnlock()
}
- 这里用了反射做类型映射，是因为 Go 泛型不支持运行时获取
T的具体类型（reflect.Type是唯一途径） - 订阅和发布都带
[T any]，确保类型安全：订阅UserCreated的 observer 不会收到OrderPaid事件 - 性能敏感场景慎用——每次
Publish都要反射取类型；高频事件建议用代码生成或手动注册表代替
泛型组合 vs 继承：什么时候该放弃泛型？
Go 没有继承，但有人试图用泛型模拟“子类共用父类行为”，比如：
type Base[T any] struct{ Data T }
func (b *Base[T]) Validate() bool { /* 通用校验 */ }
type User struct{ Base[string] }
这看似合理，实际很快会卡住：
- 嵌入的
Base[string]无法被其他函数当作 “所有带 Validate 的东西” 统一处理——因为Base[string]和Base[int]是完全不同的类型 - 你想给
User加字段，就得重复写Base[string]，失去组合的灵活性 - 真正该用泛型的地方是「算法复用」（如
Map[T, U]）或「约束抽象」（如上文的Runner），而不是模拟 OOP 结构
遇到需要多态调度的场景，老实用接口+具体类型，泛型不是银弹。
