Bridge 模式在 Go 中不用 interface{} 是因为其导致类型丢失、无静态检查、维护成本高；应使用明确行为契约的具体 interface（如 Renderer），实现层必须实现该接口，编译期验证一致性。
Bridge 模式在 Go 里为什么不用 interface{} 或空接口
Go 没有传统 OOP 的抽象类或继承层级，强行套用 UML 类图容易写出反模式代码。桥接模式的核心是「运行时解耦抽象与实现」，不是为了“看起来像设计模式”。直接用 interface{} 会导致类型丢失、无法静态检查、后期维护成本飙升。
- 抽象层（比如
Renderer）应定义明确行为契约，用具体 interface（如DrawShape()），而非泛型容器 - 实现层（如
VectorRenderer/RasterRenderer）必须实现该 interface，编译期就能验证一致性 - 若用
interface{}+ 反射分发，会失去 Go 的类型安全优势，且性能差、堆分配多
如何定义桥接的抽象层和实现层 interface
关键不是命名是否叫 “Abstraction” 或 “Implementor”，而是职责是否真正正交：抽象层负责“做什么”，实现层负责“怎么做”。两者之间只通过最小接口通信。
- 抽象层 interface 应聚焦业务语义，例如：
Shape有Draw()、ResizeBy(percentage float64) - 实现层 interface 应聚焦底层能力，例如：
Renderer有RenderCircle(x, y, r float64)、RenderRectangle(x, y, w, h float64) - 抽象层 struct 内嵌一个
Renderer接口字段，不关心它具体是 vector 还是 raster —— 这就是桥接点
示例：
type Renderer interface {
RenderCircle(x, y, r float64)
}
type Shape struct {
renderer Renderer // 桥接字段，可随时替换
}
func (s *Shape) Draw() {
s.renderer.RenderCircle(0, 0, 1)
}
为什么 Bridge 不适合用 embed 实现继承式复用
Go 的匿名字段（embed）常被误当作“继承”来用，但在桥接中，这会破坏抽象与实现的分离边界：一旦 Shape embed *VectorRenderer，它就强绑定到某一种实现，无法运行时切换，也违背桥接初衷。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- embed 是编译期静态组合，Bridge 要求的是运行时可插拔（比如根据配置选 renderer）
- embed 后，
Shape会暴露VectorRenderer的所有方法，污染抽象层 API - 正确做法是：抽象层持有 interface 字段，构造时注入，例如
NewShape(&RasterRenderer{})
实际项目中 Bridge 容易被忽略的复杂点
最常漏掉的是状态同步和生命周期管理。抽象层和实现层各自可能维护状态（比如渲染器的 DPI、抗锯齿开关；图形对象的坐标系变换），但桥接本身不自动同步这些。
- 不要假设
Renderer是无状态的——如果它缓存了设备上下文，更换renderer字段前需显式Close()或Reset() - 抽象层调用
Draw()时，若需传参控制实现细节（如是否启用阴影），应在抽象接口中加参数，而不是让调用方直接操作 renderer - Go 的 interface 值拷贝是轻量的，但若实现类型含 large struct 或指针，注意别意外复制导致状态不一致
桥接不是加一层 interface 就完事，它要求你提前想清楚哪些状态属于抽象、哪些属于实现，以及谁负责协调它们。
