Go中无语法级装饰器，应通过接口契约、中间件模式和接口代理实现非侵入式监控；需透传错误、谨慎处理接收者类型、规范指标命名与标签。
Go 里没有装饰器，别硬套 Python 思路
Go 语言本身不支持类似 Python @decorator 的语法级装饰器，强行用反射或代码生成去“模拟”，往往带来维护成本高、调用栈混乱、IDE 支持差等问题。真正可行的非侵入式监控，是靠接口契约 + 中间件模式 + 接口代理实现的。
核心思路：不改原有接口定义和实现，而是把监控逻辑“夹”在调用链路上。比如你有个 UserRepository 接口，就写一个 MonitoringUserRepository，它持有原实现，并在 Create、GetByID 等方法前后埋点。
- 不要试图用
reflect.Value.Call动态包装所有方法——类型丢失、panic 难追踪、性能损耗明显 - 避免在
init()或全局注册表里自动扫描接口——破坏显式依赖，测试难 mock - 优先用组合而非继承：新 struct 匿名嵌入原实现，再选择性重写需监控的方法
用中间件包装接口方法时，必须保留原始 error 类型
很多监控实现会在方法末尾统一记录耗时，但忽略了一个关键点：如果原方法返回的是自定义错误（如 *user.NotFoundError），而你在包装层用 fmt.Errorf("wrap: %w", err) 二次封装，下游的 errors.Is() 或 errors.As() 就会失效。
正确做法是在包装函数里直接返回原始 error 值，仅做观测，不干预控制流。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误处理要“透传”，不是“包裹”：直接
return result, err，别改err - 耗时统计用
defer+time.Now()最稳妥，比手动记开始/结束时间更不易出错 - 日志或指标上报若失败，绝不能 panic 或阻塞主流程——用异步 channel 或带超时的非阻塞写入
// 正确示例：透传 error
func (m *MonitoringUserRepo) GetByID(id int64) (*User, error) {
start := time.Now()
defer func() {
m.metrics.Observe("user_get_by_id", time.Since(start))
}()
return m.repo.GetByID(id) // 原样返回 error
}
接口代理要小心 nil receiver 和 method set 不一致
当你定义一个包装 struct 并嵌入原实现时，如果原实现是 *RealRepo 指针类型，而你嵌入的是 RealRepo 值类型，那么调用指针方法就会 panic：nil pointer dereference。这不是监控逻辑的问题，而是 Go 方法集规则导致的隐性陷阱。
更隐蔽的是：某些接口方法只在指针接收者上定义，值接收者无法满足该接口——编译期不会报错，但运行时调用会 panic。
- 统一用指针嵌入：
repo *RealRepo，且确保所有被包装方法都是指针接收者 - 用
go vet -v检查是否满足接口：它会提示 “cannot use … (value of type …) as … value in assignment: missing method …” - 测试时显式传
nil给包装 struct 的字段，验证 panic 是否可控（比如提前 guard）
监控指标命名必须带业务上下文，别只写 “rpc_latency”
单纯打点 rpc_latency 在微服务里毫无意义。你根本分不清这是用户登录的 DB 查询，还是后台定时任务的缓存刷新。指标名没上下文，告警和排查就只能靠猜。
Go 标准库的 prometheus 客户端支持 label，但很多人只用 CounterVec 却不设 label，或者 label 值写死成字符串常量，失去区分能力。
- 指标名至少包含三层：模块_动作_目标，例如
user_service_get_by_id_db_duration_seconds - 关键维度用 label：比如
method（"GET"/"POST"）、status_code（200/404/500）、db_type（"postgres"/"redis"） - 避免 label 值含高基数字段（如 user_id、request_id）——会导致指标爆炸，OOM
