composer只是包管理器，不提供接口绑定或依赖注入；真正的运行时绑定由di容器（如laravel ioc）完成，而composer的autoload仅确保类能被自动加载。
Composer 本身不提供接口绑定、依赖注入或运行时动态绑定能力——它只是一个包管理器，负责下载、安装、自动加载 PHP 类文件。所谓“用 Composer 实现核心接口与实现类的动态绑定”，是常见误解，实际起作用的是 自动加载机制（autoload） 和 后续配合的 DI 容器（如 Laravel IoC、Symfony Container、PHP-DI）。
真正能完成“接口 → 实现类”运行时绑定的，不是 composer.json，而是你写的容器配置或服务提供者。但 Composer 的 autoload 配置，是这一切能启动的前提。
为什么 composer.json 的 autoload 不等于绑定
你在 composer.json 里写：
"autoload": {
"psr-4": {
"App\": "src/"
}
}
这只是告诉 Composer：“当代码中出现 new AppServicesPaymentService() 或 use AppContractsPaymentGateway 时，请按 PSR-4 规则找到对应文件并 require 进来”。它不决定哪个类实现哪个接口，也不参与对象创建逻辑。
-
autoload是静态路径映射，无条件、无上下文、不可覆盖 - 它不读取接口定义，也不检查
implements - 即使你删掉某个实现类，只要没触发
new或use，Composer根本不会报错
真正发生“绑定”的地方：DI 容器的注册逻辑
接口与实现的解耦和切换，发生在容器配置阶段。例如在 Laravel 中：
$this->app->bind(AppContractsPaymentGateway::class, AppServicesAlipayService::class);
或使用 PHP-DI：
return [ AppContractsPaymentGateway::class => DIcreate(AppServicesWechatService::class), ];
- 这类绑定是运行时行为，可基于环境、配置、甚至请求参数动态更改
-
Composer只确保这些类能被new或make()时自动加载；没有它，容器连类都找不到 - 如果你把实现类放在未被
autoload覆盖的目录（比如legacy/），即使容器绑定了，也会抛出Class not found
常见错误：误把 autoload 当成可插拔开关
有人试图通过修改 composer.json 的 autoload 来“切换实现”，比如：
// 错误思路：注释掉一个，启用另一个
"psr-4": {
"App\Services\": "src/services/alipay/",
// "App\Services\": "src/services/wechat/",
}
这会导致两类问题：
- PSR-4 命名空间不能重复，上面写法直接使
composer dump-autoload失败 - 即使改成不同命名空间（如
AppAlipay/AppWechat），也只是让两个实现都可加载，并未指定用哪一个 - 业务代码里仍需硬编码
new AlipayService()，完全没解耦
正确做法：autoload + 容器 + 配置驱动
三者各司其职：
-
composer.json的autoload：确保所有接口、抽象类、实现类都能被自动加载（推荐统一用psr-4覆盖src/） - 容器注册（如
AppServiceProvider）：用配置项控制绑定，例如config('payment.driver') === 'alipay'时 bind 对应实现 - 实现类本身不依赖容器：只实现接口，不调用
$this->app->make()，保持可测试性
这样，换支付渠道只需改一行配置，无需动 composer.json，也不需要重新 dump-autoload。
最易被忽略的一点：很多人写了完美的容器绑定，却忘了在 composer.json 里把新实现类所在的目录加入 autoload —— 结果本地跑得通（IDE 或 require_once 临时加载了），部署后直接 Class not found。autoload 不是锦上添花，是绑定生效的底线。
