Go中桥接模式不用抽象类，因Go无继承多态，需用接口定义能力契约、组合解耦抽象与实现部分，并注意接口粒度、nil安全、资源管理及接口实现调试。
桥接模式在 Go 里为什么不用抽象类
Go 没有抽象类，也不支持继承多态，所以「桥接模式」的 Go 实现必须绕开传统 OOP 的抽象层设计。它的核心不是靠父类定义接口、子类实现，而是靠 interface{} 声明能力契约，再用组合把「抽象部分」和「实现部分」解耦。
典型错误是强行模仿 Java 写一个“抽象绘图器”结构体，再嵌套“平台实现”，结果发现字段无法多态调用，方法不能被替换——根本原因是没用接口做运行时绑定。
- 抽象部分（比如
Renderer）只依赖接口，不关心具体实现 - 实现部分（比如
OpenGLRenderer或VulkanRenderer）只实现接口，不暴露内部结构 - 桥接者（比如
Shape）持有Renderer接口，通过组合调用，而非继承
如何定义清晰的桥接接口边界
接口粒度太粗（如一个 Render() 涵盖全部图形操作）会导致实现类被迫实现无用方法；太细（如拆成 DrawLine()、DrawCircle()、SetViewport()）又让桥接逻辑散落各处。关键看谁变、怎么变。
常见场景是「图形类型」（Shape）稳定、「渲染后端」（OpenGL/Vulkan/WebGL）频繁增删。这时应把后端差异收拢进一个接口，比如：
立即学习“go语言免费学习笔记（深入）”；
type Renderer interface {
Init() error
DrawTriangle(vertices []float32) error
SetShader(shaderID uint32)
Present()
}
注意：Init() 和 Present() 是生命周期方法，DrawTriangle() 是核心能力，SetShader() 是可选扩展——这种分层让新后端只需关注自己能支持的操作，不强制实现未用功能。
组合桥接时怎么避免 nil panic 和资源泄漏
桥接对象（如 Circle）持有一个 Renderer 接口字段，但初始化时可能传入 nil，或中途被置为 nil。直接调用 r.DrawTriangle(...) 就会 panic。
- 所有桥接方法入口加
if r == nil { return errors.New("renderer not set") } - 构造函数不接受裸指针，改用工厂函数返回已校验对象，例如
NewCircle(r Renderer) *Circle - 若
Renderer涉及资源（如 OpenGL 上下文），桥接对象不应负责释放——由使用者控制生命周期，或用sync.Once+Close()显式解绑
容易忽略的一点：多个桥接对象共用同一 Renderer 实例时，不能在某个对象的 Close() 里直接销毁它，否则其他对象会失效。
接口实现分离后，如何调试调用链断裂问题
当 Circle.Render() 调用 r.DrawTriangle() 却没反应，或报错信息模糊（比如 "invalid memory address"），大概率是接口实现没真正注入，或底层实现返回了未检查的 error。
建议在桥接入口加轻量日志或断言：
func (c *Circle) Render() error {
if c.r == nil {
return fmt.Errorf("Circle.Render: renderer is nil")
}
log.Printf("Circle.Render → using %T", c.r)
return c.r.DrawTriangle(c.vertices)
}
更隐蔽的问题是实现类型没导出（首字母小写），导致外部包无法赋值给接口；或是用了指针接收器实现接口，却传了值类型——这两类都会让 interface{} 赋值失败且无编译错误，只能靠单元测试或空接口打印类型排查。
最常被跳过的环节：没写针对接口的单元测试，只测了具体实现。桥接的价值在于替换实现，不覆盖接口行为就等于没桥接。
