Go中桥接模式通过组合+接口依赖实现，抽象层持实现层接口引用，接口定义置于共享包避免循环依赖，SetRenderer支持运行时切换，性能开销主要在接口动态派发。
桥接模式在 Go 中没有接口继承，怎么组织抽象与实现？
Go 没有传统 OOP 的 interface extends interface 或抽象类，所以“桥接”不是靠语法继承实现的，而是靠组合 + 接口依赖。核心是：让抽象层（如 Renderer）持有实现层（如 LinuxRenderer、WindowsRenderer）的接口引用，而非具体类型。
常见错误是试图用嵌入 struct 模拟继承，或把实现细节暴露给抽象层——这会破坏桥接的解耦目标。
- 抽象层只定义行为契约（如
RenderShape()），不关心 OS、图形库、线程模型 - 实现层只实现该契约，可自由切换底层（OpenGL / DirectX / SVG 输出）
- 两者通过小而稳定的接口通信，例如：
type Renderer interface { RenderCircle(x, y, r float64) RenderRect(x, y, w, h float64) }
如何避免桥接后产生循环依赖或包导入混乱？
桥接结构天然涉及两个方向的依赖：抽象包需要引用实现接口，实现包又要实现该接口。若不加约束，容易出现 import cycle not allowed。
正确做法是把接口定义放在最上层共享包（如 shape/render），抽象逻辑（如 shape.Circle）和实现逻辑（如 render/opengl）各自独立 import 它，互不 import 对方。
立即学习“go语言免费学习笔记（深入）”；
- 禁止
shape/包 importrender/opengl - 禁止
render/opengl包 importshape/ - 所有实现必须满足
render.Renderer接口，但不感知 shape 类型 - 运行时由主程序组装：
circle := &shape.Circle{X: 10, Y: 20, Radius: 5} openglR := &opengl.Renderer{} circle.SetRenderer(openglR) // 组合注入 circle.Draw() // 调用 openglR.RenderCircle(...)
为什么 SetRenderer 比构造时传参更灵活？
桥接的价值在于运行时动态切换实现。如果在 NewCircle(x, y, r, rder Renderer) 中硬编码 renderer，就失去了“桥”的可替换性。
-
SetRenderer支持复用同一 shape 实例，切换不同渲染后端（比如先预览 SVG，再导出 OpenGL 帧） - 便于测试：可注入 mock
Renderer验证 draw 行为，无需启动图形上下文 - 符合 Go 的惯用法——组合优于构造参数膨胀；很多标准库类型（如
http.Server）也提供SetXXX方法 - 注意 nil 安全：调用
Draw()前应检查r.renderer != nil，或在SetRenderer中 panic 提前报错
桥接模式在 Go 中的实际性能开销在哪？
Go 的接口调用有微小间接成本（需查 iface 表），但远小于网络 I/O 或内存分配。真正影响性能的是误用桥接导致的冗余抽象。
- 不要为单个实现提前桥接（比如只有
SVGRenderer一种，还硬拆Renderer接口） - 避免接口方法过多：桥接接口应聚焦核心能力，如
Render()、Resize()，而非暴露GetGLContext()这类实现细节 - 高频调用路径（如每帧调用数十次
RenderCircle）可考虑用函数字段替代接口字段：type Circle struct { renderFunc func(x, y, r float64) }，省去接口动态派发
桥接是否必要，取决于你是否真要同时维护多套实现并允许它们独立演进。否则，一个干净的函数式封装可能更直接。
