桥接模式适用于两个维度均需独立扩展的场景，如渠道（email/sms/webhook）与业务（告警/营销/审计）均可能新增；若仅单维变化则用接口组合或策略模式更合适。
什么时候该用桥接模式，而不是策略或接口组合？
桥接模式不是“只要能换实现就上”，它专治「两个维度都可能独立扩展」的场景。比如你既要支持 EmailSender、SMSSender、WebhookSender（渠道维度），又要支持 AlertService、MarketingService、AuditService（业务维度），且未来大概率新增渠道或新增业务类型——这时桥接才真正发挥价值。
常见误判点：
- 只有一方会变（比如渠道固定为 Email + SMS，但日志级别逻辑频繁调整）→ 直接用接口组合就够了，不必强行分层
- 只是运行时选一种算法（如压缩用
Gzip还是Zstd）→ 这是策略模式，桥接不解决单点替换问题 - 所有实现都塞进一个结构体里靠
switch分支判断 → 实际是隐藏的紧耦合，没解耦
如何定义桥接的“抽象层”和“实现层”接口？
关键不是命名是否高大上，而是职责是否正交、边界是否清晰。抽象层描述“做什么”，实现层回答“怎么做”，两者之间不能有隐式依赖。
以跨平台命令执行为例：
立即学习“go语言免费学习笔记（深入）”；
《PHP设计模式指南》中文版
下载
《PHP设计模式》首先介绍了设计模式，讲述了设计模式的使用及重要性，并且详细说明了应用设计模式的场合。接下来，本书通过代码示例介绍了许多设计模式。最后，本书通过全面深入的案例分析说明了如何使用设计模式来计划新的应用程序，如何采用PHP语言编写这些模式，以及如何使用书中介绍的设计模式修正和重构已有的代码块。作者采用专业的、便于使用的格式来介绍相关的概念，自学成才的编程人员与经过更多正规培训的编程人员
-
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 服务，说明桥接没立住
桥接真正的门槛不在代码怎么写，而在第一次画出那张「哪些东西会一起变、哪些不会」的草图——图没画清，代码越写越像胶水。
