Go 的反射无法真正生成接口代理，只能对已有接口类型做动态调用封装；reflect.New 不能构造接口值，因接口需类型描述符+数据指针，而反射无法创建未声明类型；常用方式是通过 reflect.Value.MethodByName 调用已实现方法，但存在静默失败、性能损耗等限制。
Go 的反射无法真正“生成接口代理”——reflect 不能在运行时创建新接口类型或实现，所谓“代理”只能是已有接口类型的动态调用封装，本质是 reflect.Value.Call 的包装，不是代码生成，也不涉及类型系统介入。
为什么 reflect.New 不能直接构造接口代理
接口值在 Go 中由两部分组成：类型描述符 + 数据指针。反射可以创建具体类型的实例（如 reflect.New(reflect.TypeOf(&MyStruct{}).Elem())），但无法凭空构造一个满足某接口的、未声明的类型。所谓“代理”，实际是把目标对象包装进一个已定义的接口变量中，再通过反射调用其方法。
-
reflect.Interface()只能从已有reflect.Value提取接口值，不能反向“注入”行为 - 没有
reflect.MakeInterface或类似 API，Go 不允许运行时拼装接口类型 - 试图用
reflect.StructOf模拟接口字段会 panic：接口类型不可用StructOf构造
用 reflect.Value.MethodByName 实现轻量代理调用
这是最常用也最安全的做法：持有一个实现了目标接口的结构体实例，用反射按名调用其方法，再统一处理错误或日志。适用于需要拦截、重试、超时等横切逻辑的场景。
- 必须确保目标对象已实现该接口，否则
MethodByName返回空reflect.Value，后续Call会 panic - 参数需提前转为
[]reflect.Value，注意类型匹配；返回值也要手动解包，不能直接赋给原接口变量 - 性能损耗明显：每次调用都触发反射开销，不建议高频路径使用
proxy := reflect.ValueOf(myService) // myService 实现了 ServiceInterface
method := proxy.MethodByName("DoWork")
if !method.IsValid() {
panic("method DoWork not found")
}
result := method.Call([]reflect.Value{reflect.ValueOf("input")})
// result[0] 是返回值，需 .Interface() 后类型断言
替代方案：代码生成（go:generate + golang.org/x/tools/go/loader）
真要“动态生成代理”，唯一可靠路径是编译前生成代码。比如用 stringer 类工具扫描源码，提取接口定义，生成带装饰逻辑的 struct 实现。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 生成的代码可被类型检查器验证，支持 IDE 跳转和自动补全
- 避免反射，性能与手写无异；但需要维护生成逻辑，且无法响应运行时变化
- 常见错误：模板里漏掉
error返回值处理，或未导出方法导致MethodByName查不到
容易被忽略的关键限制
Go 的接口是隐式实现的，但反射对“是否实现”的判断极其脆弱：哪怕方法签名仅差一个指针层级（*T vs T），reflect.Value.MethodByName 就查不到，也不会报错，只会返回无效值——这种静默失败最容易在线上引发 panic。
另外，反射无法穿透嵌入接口（如 interface{ io.Reader; io.Writer }），必须显式列出所有方法名，不能靠“继承”自动发现。
