桥接模式用于解耦正交变化维度，通过组合替代继承实现运行时动态组装。适用于存在独立变化的多个维度、需动态切换实现且无强语义耦合的场景，如通知渠道与im平台的组合。
桥接模式不是为“修bug”而生，而是为“防爆炸”而建。当系统里出现两个或更多彼此独立、又可能随时新增的变量维度（比如车辆类型+道路材质、遥控器功能+电视品牌、图形形状+渲染平台），用继承硬绑，类数量立刻按乘法膨胀——3种车 × 4种路 = 12个类；加一种车，就得补4个新类；加一种路，又要补3个。桥接模式用组合代替继承，把每个维度拉成一条可单独生长的线，再用一根“桥”把它们连起来，运行时才决定怎么搭。
识别哪些场景真该用桥接
别一看到“多变”就上桥接。它只在满足以下条件时才真正必要：
- 存在至少两个变化方向完全正交的维度（例如：控件类型 vs 渲染后端；消息通道 vs 加密方式；支付网关 vs 对账策略）
- 这些维度不会耦合在业务逻辑里（比如“红色圆形”不是一种语义实体，只是“圆形”用了“红色”）
- 你预期未来会独立增加某个维度的新选项（如新增一个国产芯片平台，或支持一种新支付牌照）
- 需要运行时动态切换实现（比如根据用户地区自动选短信服务商，而不是编译时写死）
四步落地：从类爆炸到桥接结构
以“通知服务”为例：既要支持短信、邮件、站内信三种渠道，又要适配企业微信、飞书、钉钉三种内部IM平台。传统做法是写9个类；桥接只需6个类 + 1次组合。
-
抽实现维度接口：定义
INotificationChannel（含send()），让SmsChannel、EmailChannel、FeishuChannel分别实现 -
建抽象基类：定义
Notification抽象类，持有一个INotificationChannel字段，提供notify()入口 -
扩展抽象子类：写
OrderNotify、RefundNotify等，只关注“通知什么”，不关心“怎么发” -
运行时组装：
new OrderNotify(new DingTalkChannel())或new RefundNotify(new EmailChannel())，自由混搭
避坑要点：桥接不是万能胶
它解决的是维度解耦，不是所有耦合问题：
- 别把有强语义绑定的逻辑拆桥：比如“微信小程序登录”和“手机号密码登录”本质是不同认证流程，不是同一抽象下的不同实现，强行桥接反而模糊职责
-
抽象层不宜过度泛化：如果
Shape抽象类里开始塞exportToPdf()、animate()、validateGeometry()，说明它已承担太多角色，该拆微服务了 -
组合带来的间接性要可控：桥接后调用链变成
Shape.draw() → color.apply() → platform.render()，若中间环节超过3层，调试成本会上升，需配合日志埋点或简单代理封装 - 注意生命周期管理：被组合的实现对象（如数据库连接、HTTP客户端）若需复用或释放资源，要在抽象层明确其创建、传递与销毁时机
对比其他模式：桥接为何不可替代
它常被误认为是策略或适配器的变体，但定位截然不同：
- vs 策略模式：策略解决“同一件事的不同算法”，桥接解决“同一件事在不同维度上的正交实现”。策略是替换行为，桥接是分离轴线
- vs 适配器模式：适配器是“已有接口不匹配，临时转接”，桥接是“从设计之初就预留多维扩展空间”。一个是补丁，一个是地基
- vs 抽象工厂：工厂负责“批量创建一族对象”，桥接负责“单个对象的多维构成”。工厂管出生，桥接管成长
