Go语言实现代理模式：对象访问控制技巧

Go语言中的代理模式并非语法糖，而是依托接口与委托的手动设计实践：通过定义清晰的接口、让代理和真实对象共同实现它，并将代理字段声明为接口类型而非具体结构体，从而确保类型安全与可维护性；访问控制、日志、限流等横切逻辑必须统一收口到调用分发层，避免硬编码在方法内；警惕interface{}滥用导致的反射panic和序列化失败，优先使用泛型约束保持类型信息；同时需审慎处理defer/recover——注意执行时机、goroutine隔离及性能开销。真正有效的代理，本质是接口边界的精准划分、控制点的合理下沉与类型流动的安全护航。

Go 里没有传统代理模式的语法支持，得靠接口 + 委托手动实现

Go 没有 Proxy 类、不支持运行时动态生成代理对象，所谓“代理模式”只能靠显式定义接口、让代理结构体持有真实对象并转发调用。这不是语法糖，是设计约束——你必须提前想清楚哪些方法要拦截、哪些要透传。

常见错误是直接在代理里复制粘贴所有方法，结果真实对象一加新方法，代理就 silently 失效。正确做法是：真实对象和代理必须共用同一组接口，且代理只封装接口类型，不绑定具体结构体。

• 定义清晰的 Service 接口（比如 DoWork() error），真实对象和代理都实现它
• 代理结构体字段声明为 svc Service，而非 svc *RealService
• 避免在代理中调用 svc.(*RealService).privateMethod() —— 这会破坏接口抽象，也埋下 panic 隐患

访问控制逻辑该塞在哪？别写在方法里，要统一收口到调用分发层

把鉴权、日志、限流等横切逻辑硬编码进每个方法体内，会导致重复、难测试、无法复用。Go 的惯用解法是用函数类型包装调用，比如 func(ctx context.Context, req interface{}) (resp interface{}, err error)，再用闭包或结构体方法统一前置处理。

典型场景：HTTP handler 层做权限校验后才调用业务逻辑；RPC 客户端拦截器对每个 Call() 做 token 校验；或者数据库操作前检查租户隔离上下文。

• 用 func() error 或带 context.Context 的签名作为可拦截单元，比直接代理整个 struct 更灵活
• 不要在代理的 DoWork() 方法里写 if !hasPermission() { return ErrForbidden } —— 把权限检查抽成独立函数，由代理统一调用
• 注意 context.WithTimeout 等衍生 context 必须传给下游，否则超时控制失效

interface{} 类型穿透是坑，尤其涉及反射或 JSON 序列化时

很多代理实现为了“通用”，把入参/返回值设为 interface{}，结果在日志打印、错误包装、JSON marshal 时突然 panic：json: unsupported type: func() 或 reflect.Value.Interface(): cannot return value obtained from unexported field or method。

这问题在做通用 RPC 中间件、泛型代理工具（比如 mock 工具）时高频出现，本质是把类型擦除当成了灵活性。

• 代理层应尽量保持原始类型信息，比如用泛型约束参数为 any 而非 interface{}（Go 1.18+）
• 若必须用 interface{}，在日志或序列化前先做类型断言或用 fmt.Sprintf("%+v", v) 替代直接 json.Marshal
• 特别警惕代理里调用 reflect.Value.Call() 后返回的 reflect.Value 直接转 interface{} —— 若原方法返回私有字段，这里会 panic

别忽略 defer 和 recover 在代理中的副作用

代理常被用来统一捕获 panic（比如防止某个插件崩溃整个服务），但 defer func() { recover() }() 放错位置会导致资源泄漏或掩盖真实错误。最典型的是在代理方法开头 defer，却忘了真实对象内部也有 defer —— 两层 defer 执行顺序容易误判。

还有人用 defer 做耗时统计，结果发现 time.Since(start) 总是 0，因为 defer 在函数 return 后才执行，而某些优化路径下编译器可能提前结束。

• recover 只捕获当前 goroutine 的 panic，跨 goroutine 失效；代理若启动新 goroutine（如异步日志），需单独加 recover
• 若代理里用了 defer 关闭资源（如文件、连接），务必确认真实对象是否也做了同样操作，避免 double-close
• 性能敏感场景慎用 defer：它有固定开销，高频小函数里可能比显式调用慢 10%~20%

事情说清了就结束。代理不是加个壳就行，关键是接口边界划在哪、控制点放在哪一层、以及类型怎么安全地穿过去。

到这里，我们也就讲完了《Go语言实现代理模式：对象访问控制技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！