go中无原生aop，需用函数装饰器模拟：将业务逻辑抽为函数，用包装函数在调用前后插入横切关注点；推荐高阶函数实现日志/耗时拦截或接口组合方式封装拦截逻辑，避免反射和代码生成。
Go 里没有原生 AOP，但可以用函数装饰器模拟
Go 语言本身不支持注解、运行时字节码增强或代理对象，Spring AOP 那套基于 JVM 的机制在 Go 里根本走不通。想实现“类似效果”，核心思路是：把要拦截的逻辑提前抽成函数，再用一个包装函数（decorator）在调用前后插入横切关注点（比如日志、权限、耗时统计）。
常见错误是试图用反射强行“扫描结构体方法”或“自动注入拦截器”——这不仅性能差、类型不安全，而且无法处理闭包、接口方法、非导出字段等场景。
- 只对明确暴露的函数接口做装饰，不尝试“自动织入”
- 装饰器本身是普通函数，接收原函数为参数，返回新函数
- 被装饰函数需满足签名可统一抽象（如
func(context.Context, ...interface{}) (interface{}, error)），否则得为每种签名写单独装饰器
用高阶函数实现日志和耗时拦截
这是最常用也最稳妥的切入点。假设你有一组服务方法，都符合 func(context.Context, *Req) (*Resp, error) 签名：
func withLogging(next func(context.Context, *Req) (*Resp, error)) func(context.Context, *Req) (*Resp, error) {
return func(ctx context.Context, req *Req) (*Resp, error) {
log.Printf("start: %s", req.Op)
defer log.Printf("done: %s", req.Op)
return next(ctx, req)
}
}
使用时直接链式包裹：handler := withLogging(withMetrics(myService.DoSomething))。
立即学习“go语言免费学习笔记（深入）”；
- 注意
context.Context必须作为第一个参数传入，否则无法传递取消信号和超时控制 - 装饰器顺序很重要：比如
withRecovery应该在最外层，否则 panic 会绕过日志和指标 - 别在装饰器里修改
req或resp的底层数据（除非明确需要），避免副作用干扰原逻辑
接口+组合方式替代“切面类”
Spring 里常定义 @Aspect 类集中管理多个切点。Go 中更自然的做法是定义一个接口，把横切逻辑封装进结构体，再通过组合注入到业务对象中：
type Interceptor struct {
logger *log.Logger
metrics *prometheus.CounterVec
}
func (i *Interceptor) Before(ctx context.Context, op string) context.Context {
i.logger.Printf("before %s", op)
return ctx
}
func (i *Interceptor) After(ctx context.Context, op string, err error) {
i.metrics.WithLabelValues(op).Inc()
}
然后让业务 handler 持有该结构体：
type UserService struct {
interceptor *Interceptor
db *sql.DB
}
func (s *UserService) CreateUser(ctx context.Context, u *User) error {
ctx = s.interceptor.Before(ctx, "CreateUser")
defer func() { s.interceptor.After(ctx, "CreateUser", err) }()
// 实际逻辑...
}
- 这种方式比纯函数装饰器更易复用状态（如共享 logger、metrics client）
- 但要注意：不要让
Interceptor持有业务强依赖（比如直接持有一个*UserService），否则形成循环引用 - 如果拦截逻辑需要访问请求/响应体，就只能靠参数透传，Go 没有“JoinPoint”那样的上下文快照
别碰反射自动代理——尤其别用 github.com/kr/pty 或 go:generate 生成代理
有人会搜到用 reflect.Value.Call 包装任意方法，或者用代码生成工具为每个 service 自动生成带拦截逻辑的 wrapper。这些方案在小项目里看似“省事”，但实际踩坑极多：
-
reflect.Call性能开销大，且丢失所有编译期类型检查，panic 错误堆栈难以定位 - 生成代码会让构建变慢、diff 变复杂，一旦接口变更就得重新生成，反而增加维护成本
- 无法处理 interface{} 参数中的具体类型，也无法安全地 unwrap context 或 error
- 第三方库如
goa或grpc-go的 middleware 已经覆盖了大部分真实场景（HTTP/gRPC 层拦截），业务层再搞一套容易重叠或冲突
真正难的是跨 service 边界传递上下文语义（比如 traceID、用户身份），而不是“怎么加一行 log”。把拦截逻辑下沉到 transport 层（HTTP middleware / gRPC interceptor），比在业务函数上硬套装饰器更合理、更稳定。
