Go反射无法真正拦截方法调用，因语言无运行时方法表劫持机制；可行方案是接口+包装器组合或代码生成代理，unsafe硬劫持则被runtime限制且不稳定。
Go 反射无法真正拦截方法调用
Go 的 reflect 包不支持运行时方法拦截或 AOP 式的动态代理。你不能像 Java 的 InvocationHandler 或 Python 的 __getattribute__ 那样，在调用发生前自动捕获并重定向任意方法。这是语言设计决定的：Go 没有运行时方法表劫持机制，也没有虚函数表（vtable）重写能力。
常见错误现象是试图用 reflect.Value.Call 包一层就以为实现了“代理”，结果发现只是手动转发，完全不具备透明拦截能力——调用方仍需显式调用代理对象，且所有方法都得提前声明、一一适配。
- 反射只能做「静态转发」：你知道要调哪个方法、传什么参数，才用
reflect.Value.MethodByName+Call - 没有「调用入口钩子」：无法对未导出方法、接口方法、嵌入字段方法统一拦截
- 性能开销大：每次调用都要解析方法名、检查参数类型、打包切片、解包返回值
替代方案：用接口+包装器实现轻量代理
Go 里真正可行的通用代理，是靠组合接口与结构体包装器（wrapper），配合代码生成或手写适配层。核心思路是让代理类型实现同一接口，并在每个方法中插入逻辑（日志、重试、权限等）。
使用场景包括 gRPC 客户端中间件、数据库操作审计、HTTP handler 链式处理——它们都依赖接口抽象，而非反射黑盒。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须定义清晰的接口（如
type UserService interface { Get(id int) (*User, error) }），代理才能实现它 - 代理结构体持有原始实例：
type loggingUserService struct { inner UserService } - 每个方法手动包装：
func (l *loggingUserService) Get(id int) (*User, error) { log.Printf("Get called with %d", id); return l.inner.Get(id) } - 若方法多，可用
go:generate+genny或stringer类工具生成，但仍是编译期展开，非运行时动态
想“动态”？只能靠代码生成或服务框架
所谓“动态代理”，在 Go 中实际指：不手动为每个接口写包装器，而是通过工具在构建时生成。这比反射安全、快得多，也符合 Go 的哲学。
典型路径是用 go generate 扫描源码中的接口定义，输出对应代理结构体和方法。例如 mockgen（golang/mock）或自研的 proxygen 工具。
- 输入是接口定义（
type Store interface { Put(key string, val []byte) error }） - 输出是类似
type StoreProxy struct { Inner Store; OnPut func(key string, val []byte) ([]byte, error) } - 生成的方法里可插入钩子：
if p.OnPut != nil { return p.OnPut(key, val) } - 注意：生成代码必须和目标接口在同一包或可访问范围内；跨模块需导出接口且处理 import 路径
为什么不用 unsafe 或汇编硬劫持？
有人查资料会看到 unsafe.Pointer 替换函数指针、或修改 runtime._type 的尝试。这些不仅极度不稳定，而且从 Go 1.18 起被 runtime 明确限制——funcValue 结构体已不可写，任何绕过类型系统的操作都会触发 panic 或直接崩溃。
兼容性影响极差：同一段“黑科技”代码在不同 Go 小版本（如 1.20 vs 1.22）可能表现完全不同，甚至导致 GC 错误或内存越界。
- Go 团队多次强调：
unsafe不是为用户实现 AOP 准备的 - 即使成功，也会破坏逃逸分析、内联优化，使性能下降 3–5 倍
- CI/CD 环境下几乎无法稳定运行，调试成本远超收益
真正需要强拦截能力的场景，比如微服务治理中的全链路透传或熔断，应该交给专门的 sidecar（如 Envoy）或框架层（如 Kitex、gRPC-Go 的 UnaryInterceptor），而不是在业务代码里硬怼反射或 unsafe。
