桥接模式在go中通过组合实现而非继承，抽象层用接口字段（如renderer renderer）持有实现，构造函数负责组装；接口应按行为而非图形类型设计，避免类型断言和状态判断，所有接口字段须显式初始化防nil panic。
桥接模式在 Go 里不是靠继承，而是靠组合
Go 没有类继承，所以照搬 Java/C++ 的桥接模式写法会卡死在第一步。抽象部分（比如 Renderer）和实现部分（比如 VectorRenderer、RasterRenderer）之间不能用“父类引用指向子类对象”，得靠字段嵌入 + 接口赋值来打通。
常见错误是试图用空结构体模拟抽象基类，或者把实现类型硬塞进抽象结构体字段却不声明接口约束，导致后期扩展时类型不匹配、方法调用 panic。
- 抽象层结构体必须持有一个接口字段，例如
renderer Renderer，而非具体类型 - 实现层类型只需实现该接口，无需显式“继承”或注册
- 构造函数负责组装：传入具体实现，赋值给抽象结构体的接口字段
type Shape struct {
renderer Renderer
}
func NewCircle(r Renderer) *Shape {
return &Shape{renderer: r} // 这里完成桥接
}
接口定义要窄，但得覆盖所有桥接点
桥接成败取决于接口是否恰到好处——太宽，实现方被迫补一堆空方法；太窄，新增渲染逻辑就得改接口，破坏开闭原则。比如 Renderer 接口若只定义 RenderCircle()，那画矩形时就得加新方法，所有实现都得改。
实际中更稳妥的做法是按“绘制行为”而非“图形类型”切分，比如 DrawLine()、DrawPoint()、SetColor()，让上层 Shape 自己组合调用顺序。
立即学习“go语言免费学习笔记（深入）”；
- 避免出现
RenderCircle()、RenderSquare()这类绑定具体形状的方法 - 允许实现方对同一方法做不同解释：比如
DrawLine()在矢量渲染器里生成 SVG path，在光栅器里调用像素写入 - 如果需要传递坐标/样式等数据，统一用结构体参数（如
DrawLine(LineSpec)），别堆一堆 float64 参数
别在桥接层做状态判断，交给实现方处理
有人会在 Shape.Draw() 里写 if-else 判断当前 renderer 是矢量还是光栅，再分别调用不同逻辑——这等于把桥接又焊死了。桥接的意义是让抽象完全不知道实现细节。
典型翻车现场：在 Shape 里写 if r, ok := s.renderer.(*VectorRenderer); ok { ... }，看似灵活，实则破坏封装，后续加新渲染器就得改这里。
-
Shape.Draw()只调接口方法，不做类型断言、不查指针地址、不读实现类型的字段 - 渲染器内部可自行维护状态（如当前颜色、坐标系），但对外只暴露接口契约
- 如果真需要差异化行为（比如矢量支持缩放而光栅不支持），应该由接口方法返回错误或忽略，而不是在桥接层拦截
初始化时机错位会导致 nil panic
最常踩的坑：抽象结构体字段声明了接口类型，但忘了在构造或使用前赋值，一调 renderer.DrawXXX() 就 panic: nil pointer dereference。Go 不会像 Java 那样抛 NullPointerException 并带堆栈提示，错误信息极简，容易误判为逻辑 bug。
尤其在嵌套桥接（比如 Shape 持有 Renderer，而 Renderer 又持有 Device）时，漏一层初始化就全崩。
- 所有接口字段必须在结构体创建时显式初始化，不要依赖零值
- 构造函数应设为唯一入口，禁止外部直接 new 结构体后手动赋值
- 可在方法开头加
if s.renderer == nil { panic("renderer not set") }快速暴露问题（仅开发期，非生产兜底）
桥接不是写完接口和结构体就完了，真正难的是控制权交出去之后，你还得确保没人绕过约定偷偷窥探实现细节——这点在 Go 里特别容易被忽略，因为没编译器强制，全靠人盯。
