桥接模式在Go中通过组合+接口实现抽象与实现分离：抽象层为持有接口字段的struct，实现层为实现该接口的具体类型，接口方法仅描述行为而不绑定具体实现。
桥接模式在 Go 中没有抽象类，怎么建模抽象与实现的分离
Go 不支持继承和抽象类，所以不能照搬 Java/C++ 的桥接模式 UML 图。关键不是“模仿结构”，而是守住桥接的核心意图：让 抽象层 和 实现层 可以独立变化、互不绑定。实际做法是用组合 + 接口，把“抽象”定义为一个持有实现接口的结构体，而“实现”是一组满足该接口的具体类型。
-
抽象层是一个 struct，内嵌或持有某个接口字段（比如renderer Renderer） -
实现层是一组各自实现该接口的 struct（比如VectorRenderer、RasterRenderer） - 抽象方法内部不写具体逻辑，只调用接口方法（如
b.renderer.DrawCircle(x, y, r)）
抽象结构体要不要暴露实现接口字段
不建议直接暴露接口字段（如公开 Renderer 字段），否则使用者可能绕过抽象逻辑直接调用实现，破坏封装。应该把接口字段设为私有，并通过构造函数注入，同时提供可选的默认实现。
type Shape struct {
renderer Renderer // 小写首字母，包外不可见
}
func NewShape(r Renderer) *Shape {
if r == nil {
r = &RasterRenderer{} // 默认实现
}
return &Shape{renderer: r}
}
- 外部无法修改
renderer字段，避免状态错乱 - 构造时传入不同实现，即可切换渲染方式，不影响
Shape其他方法 - 如果需要运行时切换，可加一个
SetRenderer(r Renderer)方法，但要确保线程安全（如加锁或仅用于初始化阶段）
实现接口的方法签名设计容易踩哪些坑
接口方法参数过多、或包含具体类型（如 *svg.Document），会绑架所有实现，失去桥接意义。接口应只描述“做什么”，不规定“怎么做”或“用什么工具做”。
- ❌ 错误示例：
DrawCircle(doc *svg.Document, x, y, r float64)—— 强制所有实现都依赖 svg 包 - ✅ 正确方向：
DrawCircle(x, y, r float64)—— 坐标和半径是通用语义，各实现自行决定如何转成矢量指令或像素填充 - 若需传递上下文（如颜色、缩放），应抽成独立结构体（如
Style），而非具体三方类型
为什么桥接比策略模式更适合“多维度变化”的场景
策略模式聚焦于“同一件事的不同算法”，比如排序有快排/归并；桥接则解决“两个正交变化轴”的耦合问题——比如图形类型（Circle、Square） × 渲染方式（Raster、Vector）。如果硬用策略，你会被迫为每种组合写一个策略（RasterCircle、VectorCircle……），数量爆炸。
立即学习“go语言免费学习笔记（深入）”；
- 桥接让新增图形类型只需扩展抽象子类（
Circle、Square），不碰渲染逻辑 - 新增渲染方式只需实现
Renderer接口，不改任何图形代码 - 两者组合靠运行时注入完成，零新增类
真正难的是识别出哪两个维度是正交且都可能独立演进的——这比写代码更花时间。
