桥接模式适用于两个维度均需独立扩展的场景，如渠道（Email/SMS/Webhook）与业务（告警/营销/审计）均可能新增；若仅单维变化则用接口组合或策略模式更合适。
什么时候该用桥接模式，而不是策略或接口组合？
桥接模式不是“只要能换实现就上”，它专治「两个维度都可能独立扩展」的场景。比如你既要支持 EmailSender、SMSSender、WebhookSender（渠道维度），又要支持 AlertService、MarketingService、AuditService（业务维度），且未来大概率新增渠道或新增业务类型——这时桥接才真正发挥价值。
常见误判点：
- 只有一方会变（比如渠道固定为 Email + SMS，但日志级别逻辑频繁调整）→ 直接用接口组合就够了，不必强行分层
- 只是运行时选一种算法（如压缩用
Gzip还是Zstd）→ 这是策略模式，桥接不解决单点替换问题 - 所有实现都塞进一个结构体里靠
switch分支判断 → 实际是隐藏的紧耦合，没解耦
如何定义桥接的“抽象层”和“实现层”接口？
关键不是命名是否高大上，而是职责是否正交、边界是否清晰。抽象层描述“做什么”，实现层回答“怎么做”，两者之间不能有隐式依赖。
以跨平台命令执行为例：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
CommandExecutor是实现层接口：只定义Execute(cmd string) (string, error)，不暴露os/exec或 PowerShell 特有类型 -
PlatformRunner是抽象层结构体：持有executor CommandExecutor字段，提供RunCritical(cmd string)等封装逻辑 - 错误写法：
Execute(cmd string, timeout time.Duration)把超时参数硬编码进接口 → 后续加重试、上下文就得改所有实现；正确做法是让接口接收context.Context和Options结构体
为什么 Go 里桥接必须用字段组合，不能匿名嵌入？
Go 没有继承，但开发者常误把 type AlertService struct{ Notifier }（匿名嵌入）当成桥接——这会导致调用链泄露实现细节，破坏解耦。
正确姿势是显式声明字段名：
type AlertService struct {
notifier Notifier // 明确命名，强调“我用你”，而非“我是你”
}
好处包括：
- 避免意外调用
notifier.Send()之外的方法（比如某个SMSNotifier附带了SetRateLimit()，你不该感知） - 调试时一眼看出依赖关系，字段名即契约意图
- 后续想加中间层（如日志代理、熔断包装）可直接替换
notifier字段值，无需动结构体定义
桥接模式最容易被忽略的实战细节
桥接不是写完接口+结构体就结束了。真实项目中，这几个点决定它能不能活过三个月：
- 配置驱动：别在
main()里硬写NewAlertService(&EmailNotifier{})，应通过配置项（如NOTIFIER_TYPE=email）查表或工厂函数返回对应实例 - 接口要预留演进空间：比如
Notifier接口初期只有Send(string)，后来要加模板渲染、异步队列，就得升级为Send(ctx context.Context, msg Message) error，否则每次扩展会引发所有实现重写 - 测试友好性：抽象层单元测试应能传入
mockNotifier（满足接口即可），不依赖网络或文件系统；如果测试时还得起 SMTP 服务，说明桥接没立住
桥接真正的门槛不在代码怎么写，而在第一次画出那张「哪些东西会一起变、哪些不会」的草图——图没画清，代码越写越像胶水。
