go中proxy模式需通过接口统一行为契约，代理与真实对象均实现同一接口，在代理方法中插入鉴权等逻辑并透传context.context，禁止嵌入后绕过控制、缓存权限或新建ctx。
Go里没有class，Proxy模式得用接口+结构体组合实现
Go不支持传统面向对象的继承和抽象类，所以没法像Java那样定义Proxy继承自Subject。必须靠接口统一行为契约，再让真实对象和代理对象都实现它。关键不是“模拟类”，而是“共享接口签名”——比如DoAction()方法，RealSubject和AccessControlProxy都得有。
常见错误是直接在代理结构体里嵌入真实对象却忘了重写方法，结果调用时绕过控制逻辑。必须显式在代理的DoAction()里插入鉴权、日志或限流逻辑，再手动调用真实对象的方法。
- 定义一个
Subject接口，含所有需受控的操作方法 -
RealSubject实现该接口，专注业务逻辑 -
AccessControlProxy也实现Subject，内部持有一个Subject字段（通常是RealSubject） - 每个代理方法里先检查权限（如读/写/角色），失败就返回错误，成功才转发调用
访问控制逻辑必须放在代理方法体内，不能靠init或构造函数
有人试图在AccessControlProxy的构造函数里做一次鉴权，以为“初始化时验过，后续就安全了”。这是错的——每次方法调用都可能面对不同用户、不同上下文、不同资源ID。控制粒度必须落到每个方法调用入口。
典型场景：用户A能读资源X，但不能写；用户B能写但不能删。这些判断必须在Write()或Delete()被调用时实时发生，且传入当前ctx和resourceID参数。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 代理方法签名要保留原始参数，比如
Write(ctx context.Context, id string, data []byte) error - 鉴权逻辑应调用独立的
CanWrite(ctx, id)函数，而非硬编码规则 - 避免在代理里缓存用户权限——权限可能动态变更，每次调用都应查最新状态
- 如果鉴权失败，直接返回
errors.New("access denied")，不要调用下游
context.Context传递是Go代理中控制链路的关键粘合剂
Go生态里，context.Context不只是超时控制，更是携带认证信息（如user.ID、role）的唯一可靠通道。代理若不透传ctx，下游就拿不到调用方身份，鉴权就成了空谈。
容易踩的坑是代理方法里新建context.Background()或用context.TODO()代替传入的ctx——这等于把用户身份“丢在门口”。另一个问题是没用context.WithValue()注入额外元数据（比如请求来源IP），导致审计日志缺失。
- 代理方法签名必须以
ctx context.Context为第一个参数 - 所有下游调用（包括
RealSubject方法）都要传同一个ctx，或基于它派生子ctx - 如需增强上下文，用
context.WithValue(ctx, key, value)，key建议用私有类型避免冲突 - 别在代理里取消
ctx——那是调用方的责任；代理只消费，不干预生命周期
性能敏感场景下，避免在代理里做同步IO或复杂计算
代理本意是解耦和增强，不是加瓶颈。如果每次DoAction()都同步查一次数据库验证权限，吞吐量会断崖下跌。尤其高频接口（如心跳、计数器），鉴权应尽量走内存缓存或本地策略引擎。
更隐蔽的问题是代理里启动goroutine但没处理panic或泄漏——比如用go log.Audit(...)却不recover，一旦日志服务挂掉，整个代理逻辑可能因panic中断。
- 高频接口的权限检查优先用
sync.Map或ristretto缓存结果，TTL设短（如5s）保证时效性 - 异步操作（如审计日志）务必用
defer recover()兜底，且避免阻塞主流程 - 代理本身不应持有大对象（如未序列化的用户完整profile），按需从
ctx取最小必要字段 - 压测时重点对比代理开启/关闭的P99延迟，差值超过2ms就得优化鉴权路径
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
