thinkphp 无内置 bridge 类，桥接模式需开发者基于容器和接口手动实现；核心是抽象类持接口类型成员并运行时注入具体实现，而非框架提供现成组件。
ThinkPHP 本身没有内置的 Bridge 模式类或命名空间，也不提供开箱即用的桥接抽象层。所谓“ThinkPHP 中使用桥接模式”，是开发者基于其框架结构（如依赖注入容器、接口契约、多态调用）手动实现的解耦设计，并非框架原生能力。
为什么 ThinkPHP 项目里看不到 Bridge 类？
因为 Bridge 是一种架构意图，不是具体组件。ThinkPHP 的 think\Container 和接口绑定机制（bind() / singleton()）天然支持桥接所需的“抽象引用 + 运行时替换”能力，但框架不会替你定义 Shape 或 Color 这类业务抽象——这些必须由你根据实际场景建模。
- 框架只管“怎么换实现”，不管“换什么抽象”
-
app\common\interface\PaymentChannel是你定义的抽象，不是 TP 提供的 - 试图在
think\facade或think\contract下找Bridge类会失败
如何在 ThinkPHP 中真正落地桥接结构？
关键不是继承某个基类，而是控制抽象与实现之间的组合关系。以支付模块为例：
- 定义实现接口：
app\common\interface\PaymentGateway，含pay()、refund() - 写多个具体实现：
app\common\gateway\WechatPay、Alipay、UnionPay - 定义抽象业务类：
app\common\service\OrderService，构造时接收PaymentGateway实例，不 new 具体类 - 在控制器中通过容器解析：
app()->make(OrderService::class, ['gateway' => app()->make(WechatPay::class)])
这样，OrderService 不依赖任何具体支付 SDK，新增 PayPal 只需实现接口并传入，无需修改业务逻辑。
容易踩的坑：把桥接写成工厂+单例混合体
常见错误是把 PaymentFactory::create('wechat') 塞进业务类，再用 switch 加载不同实例——这仍是条件分支耦合，不是桥接。
- 桥接要求抽象类持有 接口类型 成员变量，且该变量在运行时可被任意
ConcreteImplementor替换 - 如果
OrderService构造函数参数是string $type，并在内部new $class，就破坏了桥接前提 - TP 的
config('pay.driver')配置驱动方式，适合做工厂入口，但桥接对象本身必须由外部注入，不能自己读配置创建
性能与扩展性的真实影响
桥接在 TP 中几乎无运行时开销，但对代码组织有隐性成本：
- 每个维度变化都要拆出接口 + 至少一个实现类，初期代码量略增
- 调试时不能直接跳转到具体实现，需先看类型提示再查容器绑定
- 若抽象粒度太粗（如只定义一个
doWork()），会导致实现类职责过重；太细（如每个方法一个接口）又增加维护负担 - TP 的自动加载和容器缓存让多次
make()调用几乎无性能损失，但滥用app()->get()获取未绑定接口会抛出InvalidArgumentException
真正难的是判断哪部分该抽象、哪部分该实现——比如“通知渠道”适合作为桥接维度，“用户等级计算规则”也适合，但“日志格式化”通常用策略模式更自然。这个边界没有银弹，得靠对业务变化频率的预判。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
