桥接模式通过abstraction持有implementor引用实现解耦，如datasource接口与hikaridatasource等实现类、platformtransactionmanager与各事务管理器，避免继承绑定，支持运行时灵活替换底层实现。
桥接模式是解决“业务逻辑稳定，但底层实现（如数据库驱动）频繁变化”这类问题最直接有效的结构设计方式。它不靠继承硬绑定，而是让业务层持有驱动接口的引用，在运行时动态组合——这才是真正能应对 MySQL 切换到 PostgreSQL、或加一个 TiDB 支持的解耦姿势。
为什么 DataSource 接口天然适配桥接模式
Spring 的 DataSource 就是典型的桥接抽象层：它只声明 getConnection() 这类高层契约，完全不关心背后是 HikariCP、Druid 还是 Apache DBCP。而每个具体实现类（如 HikariDataSource、DruidDataSource）就是 ConcreteImplementor，封装了连接池初始化、JDBC URL 解析、事务隔离级别适配等细节。
关键点在于：DataSource 不继承任何数据库特定类，也不依赖某一种 driver；它通过组合持有底层连接能力，把“获取连接”这个动作委托出去。这正是桥接模式中 Abstraction 持有 Implementor 引用的标准写法。
PlatformTransactionManager 是怎么桥接不同事务机制的
Spring 事务不是靠抽象类继承来支持多种数据库，而是靠桥接：抽象层 PlatformTransactionManager 定义 getTransaction()、commit() 等行为；具体实现如 DataSourceTransactionManager（面向 JDBC）、JtaTransactionManager（面向 JTA）、R2dbcTransactionManager（面向响应式数据库）各自实现这些方法。
- 业务 Service 层只依赖
PlatformTransactionManager接口，完全不知道底层用的是哪套事务模型 - 切换事务机制只需改配置或 Bean 定义，不碰业务代码
- 新增一种事务实现（比如对接 Seata 分布式事务），只要实现
PlatformTransactionManager，其他模块零修改
自己手写桥接时，最容易踩的坑是“桥没搭稳”
常见错误包括：
- 在 Abstraction 类里直接 new 具体 Implementor（比如
new MySQLConnectionImpl()），破坏了运行时可替换性 - Abstraction 和 Implementor 之间出现双向依赖，比如 Implementor 反过来调用 Abstraction 的 protected 方法，导致耦合回流
- 把本该属于 Implementor 的状态（如连接超时、重试次数）塞进 Abstraction，模糊了职责边界
- 误把策略模式当桥接——比如只换 SQL 执行逻辑但不换连接获取方式，那只是
Statement层面的策略，不是 DataSource + TransactionManager 两个正交维度的桥接
真正稳的桥接，是 Abstraction 构造时传入 Implementor 实例，且全程只调用其公开接口方法；所有数据库特异性逻辑（如 Oracle 的 ROWNUM 分页、PostgreSQL 的 ON CONFLICT）必须收口在 ConcreteImplementor 内部。
桥接最难的不是写代码，而是识别出哪些是稳定抽象（比如“查用户”“开事务”），哪些是易变实现（MySQL 驱动、Oracle JDBC Thin、R2DBC Postgres）。一旦维度划错，桥就成了一根单向独木桥。
