桥接模式在Go中通过接口组合而非继承实现：高层逻辑与底层实现共同依赖同一接口，用结构体嵌入接口类型自动提升方法，确保正交变化分离且无循环依赖。
桥接模式在 Go 里没有 interface{} 就别硬桥
Go 没有传统 OOP 的抽象类或继承链，所谓“桥接”不是把 Abstraction 和 Implementor 拉两条继承线再连起来——而是靠组合 + 接口契约。核心就一条：让高层逻辑依赖一个接口，底层实现也实现这个接口，中间不写死、不强耦合。
常见错误是试图模仿 Java 写出 AbstractDisplay 和 DisplayImpl 两套结构体加指针嵌套，结果接口定义模糊、方法职责重叠、调用链绕三圈还搞不清谁该 new 谁。
- 抽象侧只定义行为意图（如
Render()、Resize()），不碰具体设备、协议、存储路径 - 实现侧只管怎么干（如用
svg.Renderer还是pdf.Writer），不关心上层是否要支持撤销、缓存或权限校验 - 桥接点就是那个接口变量——它得是字段，不是参数传一次就丢；否则不是桥接，是临时适配
用 embed 实现轻量桥接比嵌套指针更 Go
很多人一想“分离”，立刻写 type Abstraction struct { impl Implementor }，然后所有方法都转调 a.impl.DoX()。这没错，但啰嗦、易漏、难测试。Go 1.16+ 的 embed 不适用这里，但结构体嵌入（anonymous field）才是真香：
<pre class="brush:php;toolbar:false;">type Renderer interface {
DrawShape(shape string)
SetColor(c string)
}
<p>type SVGRenderer struct{ /<em> ... </em>/ }
func (s SVGRenderer) DrawShape(shape string) { /<em> ... </em>/ }
func (s SVGRenderer) SetColor(c string) { /<em> ... </em>/ }</p><p>type VectorDisplay struct {
Renderer // ← 直接嵌入，方法自动提升
scale float64
}</p><p>func (v *VectorDisplay) Render() {
v.DrawShape("circle") // 不写 v.Renderer.DrawShape()
v.SetColor("#ff0000")
}</p>这样既避免重复转发，又保留替换灵活性：只要换掉 Renderer 字段值，整个 <code>VectorDisplay 行为就切换了。注意嵌入的是接口类型，不是具体结构体——否则又锁死了实现。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 嵌入接口时，确保接口方法名不冲突（比如两个接口都有
Close()，编译失败） - 如果需要访问实现侧私有字段（如
SVGRenderer.cache），就不能嵌入接口，得退回去用显式字段 + 转发 - 嵌入后方法集属于外层类型，但接口断言仍看实际赋值对象，这点不影响桥接语义
什么时候该用桥接？看这三个信号
不是所有组合都是桥接。真需要桥接，通常是因为你在同时应对两组正交变化：比如「图表类型」（柱状图/折线图/热力图）和「输出目标」（Web 渲染/打印 PDF/导出 PNG）。这两组变化各自独立演进，硬写 if-else 或工厂方法会爆炸。
- 发现代码里频繁出现类似
if output == "pdf" { drawPDF(...) } else if output == "svg" { drawSVG(...) }，且每种 output 下还要区分 chart 类型 - 单元测试里，每次改一个渲染逻辑就得同步改 N 个图表类型的测试用例
- 新加一种输出格式（比如 WebP）时，被迫去每个图表结构体里加一段新逻辑，而不是只写一个新实现
这时候就把“图表行为”抽成接口，把“输出能力”也抽成接口，中间用组合连接——这才是桥接在 Go 里的落地形态。
容易被忽略的初始化陷阱：实现体不能依赖抽象体
最隐蔽的坑是循环依赖：比如 PDFRenderer 构造时偷偷调了 Chart.GetTitle()，而 Chart 又持有 Renderer。表面能跑，但一旦 Chart 加了缓存或异步加载，PDFRenderer 初始化就会卡住或 panic。
桥接的前提是单向依赖：抽象 → 接口 → 实现。实现体必须是纯函数式、无状态或仅依赖基础库（io.Writer、bytes.Buffer 等）。
- 实现体里禁止出现对任何抽象结构体的 import（哪怕只是类型别名）
- 如果实现需要配置，用
Option函数或独立 config 结构体传入，不要塞进抽象体字段 - 日志、监控等横切关注点，统一由抽象层注入
log.Logger或telemetry.Tracer，实现体只接收接口，不自己 init
桥接真正的复杂点不在结构，而在划清这条依赖边界——越早检查 import 图，越少后期重构。
