bridge模式在go中必须用显式接口字段（如renderer renderer）而非embed接口实现：避免方法污染、静默覆盖、mock困难、空值panic及性能损耗，确保运行时可插拔与可测试性。
Bridge 模式在 Go 里不是“写个抽象类再继承”，而是靠接口字段 + 显式组合立住的；不这么干，迟早掉进 nil panic、类型断言、接口污染或性能黑洞。
为什么 Shape.renderer 必须是显式字段，不能 embed 接口
有人写 type Circle struct { Renderer }，以为能省个字段名——结果：Circle 自动获得 RenderCircle() 方法，和自身逻辑混在一起，单元测试时 mock 不了、日志打不了、空值检查也做不了。
更危险的是，如果 Renderer 和 Circle 都有 Draw() 方法，编译器会静默覆盖，调用行为完全不可控。
- 必须声明为
renderer Renderer，名字清晰、可读、可测 - 构造函数里强制传入非 nil 实现，避免运行时
panic: nil pointer dereference - 字段名保留调试线索：比如
log.Output比匿名嵌入更容易定位日志输出点
Renderer 接口该怎么设计才不翻车
接口太窄，加个新图形就得改所有实现；太宽，光栅渲染器被迫实现 ExportSVG() 这种它根本不用的方法。
正确切法是按「行为」而非「类型」定义方法：
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 用
DrawLine(spec LineSpec)，别用RenderLine(x1, y1, x2, y2 float64)—— 参数太多难维护，且无法扩展样式 - 避免
RenderCircle()、RenderSquare()这类绑定形状的方法，否则新增Hexagon就得改接口 - 把坐标、颜色、线宽等封装进结构体参数，比如
type DrawPointSpec struct { X, Y float64; Color RGBA }
如何安全地切换 renderer 而不破坏现有逻辑
桥接的价值就在运行时换实现。但直接赋值 c.renderer = &RasterRenderer{} 前，得确认三件事：
-
c.renderer原来不是nil，否则旧实现没清理干净可能残留状态（比如缓存的画布句柄） - 新
RasterRenderer是否实现了全部接口方法？Go 编译期能检查，但若用反射或插件加载，就得加if r, ok := newR.(Renderer); !ok { ... } - 是否需要同步状态？比如当前画笔颜色，应由
Renderer自己维护，Circle.Draw()不该传color参数去干预
推荐做法：封装一个 SetRenderer(r Renderer) 方法，在里面做空值防护和兼容性校验。
高频调用场景下怎么避开接口动态分发开销
每次 r.DrawPoint(p) 都要查接口底层类型和方法地址，图形渲染、实时日志等场景下，累积延迟明显。
- 对性能敏感路径，考虑用函数字段替代接口字段：
drawPoint func(spec DrawPointSpec)，初始化时绑定具体实现 - 或者用
switch r := renderer.(type)在入口做一次类型判断，之后转为直接调用（但会牺牲扩展性） - 别为了“理论简洁”在每帧渲染里调十次接口方法——Go 的接口不是免费午餐
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
