go中应优先用函数类型、接口组合、代码生成和defer替代反射，避免10–100倍性能损耗及编译检查丢失。
用函数类型替代反射调用
反射在 Go 中开销明显：每次 reflect.ValueOf、MethodByName、Call 都涉及类型检查、栈帧切换和权限校验，实测比直接函数调用慢 10–100 倍。真正轻量的替代方案是把行为抽象为函数类型，让编译器静态绑定。
常见错误是为“通用执行”硬套反射，比如写一个 Invoke(methodName string, args ...interface{})，结果所有调用路径都拖慢 20ms+。
- 把可变逻辑定义为函数签名，如
type Handler func(ctx Context, req interface{}) error - 注册时传入具体实现（闭包或方法值），而非字符串名；例如
router.POST("/user", user.Create)，不是router.POST("/user", "user.Create") - 需要参数校验？用结构体字段标签 + 编译期生成的校验函数（
go:generate），而非运行时反射解析
用接口组合替代反射式对象代理
想做日志/鉴权/缓存等横切逻辑？别用反射包装每个方法——Go 的隐式接口 + 组合更直接。动态代理在 Go 中既难写又难测，且失去编译检查。
典型陷阱是写一个泛型代理 struct，内部用 reflect.Value.Call 转发所有方法，结果 panic 频发（比如方法签名不匹配、指针接收者误传值）、IDE 无法跳转、单元测试必须 mock 反射路径。
- 定义窄接口，如
type Storer interface { Save(key string, val []byte) error }，只暴露实际需要的方法 - 用装饰器模式组合：写
func WithLogging(s Storer) Storer，内部直接调用s.Save，不碰反射 - 若需统一拦截多个不同接口（如
Storer和Fetcher），用泛型函数封装共性逻辑，而非反射遍历方法
用代码生成（go:generate）替代运行时反射
当反射用于“模拟泛型”或“自动绑定字段”，比如 ORM 映射、配置加载、gRPC 客户端生成，应优先用 go:generate 在构建期生成类型安全代码，而非启动时反射扫描。
很多人误以为生成代码“不够灵活”，但实际中 95% 的反射使用场景都是固定结构（struct 字段、HTTP handler 签名、数据库表列），生成后零运行时开销，且 IDE 支持完整、错误提前暴露。
- 用
github.com/vektra/mockery或自定义go:generate脚本生成 mock，避免gomock运行时反射 mock - 配置解析：用
github.com/mitchellh/mapstructure是反射方案，但更优解是用go:generate把 YAML/JSON Schema 转成结构体 + 解析函数 - 注意：生成代码要进 Git，否则 CI 构建失败；且生成逻辑必须幂等，避免反复修改同一文件引发冲突
用 defer + 函数值封装资源生命周期
反射常被滥用在“统一关闭资源”上，比如遍历 struct 字段找所有 io.Closer 并调用 Close()。这不仅慢，还容易漏掉嵌套字段或误关已关闭句柄。
真正的 Go 风格是显式管理：用 defer 绑定具体资源，或把清理逻辑作为函数值传入构造函数。
- 创建对象时，接受
onClose func() error参数，在析构时直接调用，不查类型 - HTTP handler 中清理临时文件？写
defer os.Remove(tmpPath)，而不是反射找所有*os.File字段 - 需要批量关闭？用
sync.WaitGroup+ 显式Close()调用链，而非反射聚合所有 closeable 字段
最易被忽略的是：反射不是“慢在调用”，而是“慢在破坏了编译器优化机会”。一旦用了 interface{} + reflect，内联、逃逸分析、常量传播全失效。宁可多写几行类型明确的代码，也不要换一行“看起来更通用”的反射。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
