Go 里怎么写一个基础的 Proxy 接口代理
Go 没有语言级的代理语法（比如 JavaScript 的 Proxy），所有代理逻辑都得靠接口+结构体手动实现。核心思路是：定义一个与目标对象相同的接口，让代理类型实现该接口，并在方法中控制对真实对象的调用时机或权限。
常见错误是直接代理指针但忽略 nil receiver，或者把代理和被代理对象耦合进同一包导致循环依赖。
- 代理类型必须实现和真实对象**完全一致的接口签名**，包括参数名、顺序、返回值个数和类型
- 代理内部通常持有一个
*RealObject字段，但初始化时可以为nil—— 这是延迟加载的关键 - 如果真实对象构造开销大（如连接数据库、读大文件），代理应在首次调用时才 new 它，而不是在代理创建时就初始化
- 注意方法集：只有指针接收者的方法能被
*Proxy调用；若真实对象用值接收者实现接口，代理字段也建议用值类型（避免意外拷贝）
用 Proxy 实现访问控制（ACL）时要注意什么
访问控制不是加个 if 就完事。真实场景中，权限检查往往需要上下文（比如当前用户 ID、token）、可能异步（查 Redis）、甚至带副作用（记录审计日志）。硬塞在每个代理方法里会导致重复逻辑和难以测试。
典型错误是把鉴权逻辑写死在代理方法里，结果改个策略就得改十几个函数；或者忘记处理 error 分支，让未授权请求静默失败。
立即学习“go语言免费学习笔记（深入）”；
- 把鉴权抽成独立函数，签名类似
func(ctx context.Context, method string, args ...interface{}) error - 代理方法里先调
checkAccess(ctx, "ReadUser")，失败直接 return 错误，不碰真实对象 - 别在代理里缓存用户权限——权限可能动态变更，每次调用都应做实时校验（或设短 TTL 的本地 cache）
- 如果真实对象方法本身返回
error，代理要区分：是权限拒绝（ErrForbidden），还是下游失败（io.EOF），二者 HTTP 状态码应不同
延迟加载（Lazy Load）代理的坑在哪
延迟加载看着简单：字段初始为 nil，第一次调用时初始化。但 Go 的并发环境下，多个 goroutine 同时触发初始化会导致重复构造、资源泄漏，甚至 panic（比如多次 dial 同一 TCP 地址）。
另一个隐形问题是：初始化失败后，下次调用是否重试？还是永久卡在失败状态？这直接影响可用性。
- 必须用
sync.Once保证初始化只执行一次，不要手写 double-check lock（容易漏 volatile 或 memory order） - 把初始化逻辑封装进私有方法，例如
proxy.ensureReal()，内部用once.Do(...) - 如果初始化可能失败（如网络不可达），代理应缓存失败错误，并在后续调用中直接返回它，而不是每次都重试
- 考虑是否支持“软失败”：比如初始化失败时返回默认值或降级对象，而非直接报错（视业务容忍度而定）
Proxy 和 interface{} 类型断言混用会出什么事
有人想“通用代理”，用 interface{} 存真实对象，再靠反射调方法。这在 Go 里极不推荐：性能差、类型不安全、无法静态检查接口一致性，且 panic 信息难追踪。
更常见的错误是代理实现了某个接口，但使用者却用 interface{} 接收，然后试图断言回原类型——断言必然失败，因为代理类型 ≠ 真实类型。
- 代理必须显式实现目标接口，不能靠运行时断言绕过类型系统
- 不要在代理内部用
reflect.Value.Call调方法——失去编译期检查，IDE 无法跳转，go vet 也扫不出来 - 如果真需要多态调度，用组合 + 显式接口转换，例如
func (p *UserProxy) AsReader() io.Reader - 单元测试时，直接 mock 接口比 mock 代理本身更轻量；代理的测试重点应是“是否按预期调用了真实对象”，而非“是否实现了接口”
代理模式在 Go 里本质是种设计取舍：你放弃了一部分语言的简洁性，换来对调用链路的完全掌控。最容易被忽略的是并发安全和错误传播路径——这两个点不提前想清楚，上线后问题往往出现在高并发或异常网络下，而不是功能逻辑里。
