桥接模式在Go中通过组合+接口实现解耦，抽象层（如Shape）持实现层接口（如Renderer）字段并委托操作，确保两者扩展正交；Renderer必须为接口，由具体结构体实现；抽象结构体需在构造时注入实现，避免写死；方法签名变更需所有实现同步更新，接口粒度应合理切分。
桥接模式的核心拆分原则
桥接模式在 Go 里不是靠继承，而是靠组合 + 接口解耦。关键判断标准是：抽象层（比如 Shape）不直接实现具体行为，而是持有一个实现层接口（比如 Renderer）的字段，所有绘制、序列化等操作都委托给它。
这种拆分让 Shape 的扩展（如新增 Circle、Rectangle）和 Renderer 的扩展（如新增 VectorRenderer、RasterRenderer）完全正交——加一个新图形不用改渲染器，加一种新渲染方式也不用动图形定义。
Go 中必须用接口定义实现层
Go 没有抽象类，所以“实现层”必须是一个接口，由具体结构体实现。常见错误是把实现层写成具体类型或带方法的 struct，导致抽象层无法灵活切换实现。
-
Renderer必须是接口，例如：type Renderer interface { RenderCircle(radius float64) } - 具体实现如
SVGRenderer或CanvasRenderer只需实现该接口，不需继承任何基类 - 抽象结构体（如
Circle）持有renderer Renderer字段，构造时注入
构造时注入实现，避免全局或单例绑定
桥接失效最常见的原因是把实现层写死在抽象结构体内，比如在 Circle 的 NewCircle() 里直接初始化 &SVGRenderer{}。这会让桥接退化为普通组合，失去运行时替换能力。
立即学习“go语言免费学习笔记（深入）”；
正确做法是把实现层作为参数传入构造函数：
type Circle struct {
radius float64
renderer Renderer
}
func NewCircle(radius float64, r Renderer) *Circle {
return &Circle{radius: radius, renderer: r}
}
这样调用方可以自由选择：NewCircle(5.0, &SVGRenderer{}) 或 NewCircle(5.0, &RasterRenderer{})，甚至测试时传入 mock 实现。
注意方法签名一致性与空实现风险
当实现层接口方法增多（如增加 RenderRectangle(width, height float64)），所有已有的 Renderer 实现都必须补全，否则编译失败。这不是缺陷，而是桥接的契约约束——但容易被忽略，尤其在迭代中新增图形类型时。
- 如果某 Renderer 不支持某种图形（如
ConsoleRenderer不适合画圆），应在方法内明确返回 error 或 panic，而不是静默忽略 - 避免用空接口（
interface{}）替代Renderer，会丢失类型安全和 IDE 支持 - 不要在抽象层加“适配逻辑”（比如在
Circle.Render()里判断if r is *SVGRenderer），这破坏了桥接的委托本质
真正难的是保持接口粒度合理：太粗（如一个 Render(shape Shape)）会让实现层承担过多分支逻辑；太细（每个图形一个方法）又导致接口膨胀。得根据实际渲染目标的差异点来切分方法，而不是按图形种类。
