laravel 6 容器不支持接口到多个实现类的运行时多态绑定，bind() 会覆盖前值；需用工厂闭包根据请求上下文动态解析，或采用命名绑定+make() 显式获取。
Laravel 6 中无法直接用接口绑定实现“运行时多态”——容器不支持将一个接口绑定到多个实现类并按需解析，bind() 或 singleton() 都只能指定唯一目标。所谓“多态绑定”，本质是工厂模式驱动的动态解析，不是容器原生能力。
为什么不能直接 bind 接口到多个类
当你写 $this->app->bind(ProcessorInterface::class, PostProcessor::class)，Laravel 就只认这一个；再 bind 一次会覆盖前值。你没法让 app(ProcessorInterface::class) 有时返回 PostProcessor、有时返回 VideoProcessor——容器没这个上下文感知机制。
常见错误现象：Class App\Contracts\ProcessorInterface does not exist（没绑定）或始终返回同一个实现类（覆盖了）。
- 接口本身不能被实例化，必须靠具体类
- 容器的 bind 是静态映射，不接受运行时参数
- 试图在构造函数里注入
ProcessorInterface并期望自动切换，必然失败
用工厂闭包 + 请求上下文做动态解析
真正可行的做法，是在容器绑定中塞一个闭包，把“选哪个实现”的逻辑收进来。比如根据请求中的 type 参数决定用哪个处理器：
$this->app->bind(ProcessorInterface::class, function ($app) {
$type = request()->input('type', 'post');
return match($type) {
'post' => new PostProcessor(),
'video' => new VideoProcessor(),
'image' => new ImageProcessor(),
default => throw new InvalidArgumentException("Unknown processor type: {$type}"),
};
});
这样每次 app(ProcessorInterface::class) 调用都会重新执行闭包，拿到当前请求对应的实例。
- 闭包内可用
request()、session()、路由参数等判断上下文 - 不要在闭包里直接 new 太多对象——考虑用
$app->make()让容器管理依赖 - 如果处理器自身有依赖（如
LoggerInterface），确保它们已正确绑定
更健壮：注册为命名绑定 + 手动解析
比起全局绑定接口，更推荐显式命名各实现，并在需要处按需解析。避免污染容器默认行为，也方便单元测试 mock：
// 在服务提供者中
$this->app->bind('processor.post', PostProcessor::class);
$this->app->bind('processor.video', VideoProcessor::class);
$this->app->bind('processor.image', ImageProcessor::class);
// 使用时
$processor = $this->app->make('processor.' . request()->input('type', 'post'));
这种方式完全绕过接口绑定限制，又保留了扩展性。加新类型只需新增一个命名绑定，不改原有逻辑。
- 命名绑定不会互相覆盖，安全
- 可配合
makeWith()传参（如传入 ID 或配置数组） - 测试时可直接
$app->instance('processor.post', $mock)替换
别踩 morphMap 的坑：这不是多态绑定
看到资料里提 morphMap() 就想套用到接口绑定上？别试。那是给多态关联（morphTo）用的字段别名映射，和容器绑定完全无关。你在 AppServiceProvider 里调 Relation::morphMap()，对 ProcessorInterface 一点作用都没有。
真正容易被忽略的点：工厂闭包里的 request() 在命令行或队列中不可用。如果你的处理器也会被 Artisan 命令或 Job 调用，必须把上下文参数显式传进去，不能依赖全局 request 实例。
