桥接模式在Go中通过组合+接口字段实现抽象与实现的彻底分离。Abstraction为持Implementor接口字段的struct，RefinedAbstraction增强功能而不改变绑定，具体实现仅实现接口且不知上层存在。
桥接模式在 Go 里不是靠抽象类或接口继承来“模拟”，而是用组合 + 接口字段直接持有实现，核心是把“抽象”和“实现”两根线彻底分开，各自演化互不牵扯。
为什么 Go 不需要传统桥接模式的继承结构
Go 没有类、没有继承、也没有抽象类，所以照搬 Java/C++ 的桥接写法只会让代码变重、变绕。真正的解耦关键在于：抽象层只依赖接口，实现层只实现接口，中间靠字段组合连接。
-
Abstraction是一个 struct，内部持有一个Implementor接口类型的字段 -
RefinedAbstraction是对Abstraction的增强（比如加缓存、加日志），不改变其与实现的绑定方式 - 所有具体实现（如
ConcreteImplementorA）只实现Implementor接口，完全不知道上层抽象的存在
标准桥接结构的 Go 实现示例
以“消息发送”为例：发送逻辑（推送/邮件/SMS）和渠道策略（立即发/延时发/重试发）要正交组合。
type Sender interface {
Send(content string) error
}
type DeliveryStrategy interface {
Deliver(s Sender, content string) error
}
type MessageService struct {
sender Sender
strategy DeliveryStrategy
}
func (m *MessageService) Send(content string) error {
return m.strategy.Deliver(m.sender, content)
}
// 具体实现
type SMSSender struct{}
func (s SMSSender) Send(content string) error {
println("SMS:", content)
return nil
}
type DelayedStrategy struct{}
func (d DelayedStrategy) Deliver(s Sender, content string) error {
println("Delaying...")
return s.Send(content)
}
使用时自由组合：ms := &MessageService{sender: SMSSender{}, strategy: DelayedStrategy{}} —— 抽象（MessageService）和实现（SMSSender / DelayedStrategy）完全独立编译、测试、替换。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：别把接口塞进接口
常见错误是定义一层又一层嵌套接口，比如：
- 错误：让
DeliveryStrategy接口方法接收interface{ Send(string) error }—— 这会让实现无法内联、增加类型断言开销 - 错误：给
MessageService加SetSender(Sender)和SetStrategy(DeliveryStrategy)方法，导致运行时才绑定，失去编译期检查和可读性 - 正确做法：字段在初始化时注入，接口定义窄而稳定（只暴露必要方法），避免“为扩展而扩展”
什么时候该用桥接，而不是简单封装或函数选项
桥接模式的价值只在两个维度都存在**多变且需独立演进**时才凸显：
- 多个发送方式（SMS / Email / Push） × 多个投递策略（Direct / Batch / Retry） → 共 3×3=9 种组合，用桥接可写 3+3=6 个类型，而非 9 个具体实现
- 如果只有 1–2 种策略，或策略逻辑极简（如只是加个
time.Sleep），直接用函数参数或结构体字段更轻量 - 若策略间共享大量状态（如共用连接池、上下文），桥接反而会迫使你在每个
Implementor里重复管理，此时应考虑用策略模式 + 共享依赖注入
真正难的是识别出哪部分该划为“抽象轴”，哪部分该划为“实现轴”——这没法靠模式名称判断，得看业务变化频率和团队协作边界。
