Laravel 6 容器首次解析即锁定绑定，App::bind() 在条件分支中不生效，因单例已缓存；应改用带运行时判断的 bind 闭包或 Manager 模式实现动态切换。
不难，但必须绕开 Laravel 6 的容器绑定限制——它不支持运行时按条件覆盖已注册的单例，直接 bind() 或 singleton() 后再 conditionally bind 会失效。
为什么 App::bind() 在条件分支里不生效
Laravel 6 的服务容器在第一次解析某个抽象（比如接口）时，就缓存了对应的实例或闭包。后续所有 resolve() 都复用这个结果，不管你在中间加了多少 if/else 调用 App::bind()。它不是“每次请求重绑”，而是“首次绑定即锁定”。
- 你写了
App::bind(Handler::class, function () { return new V2Handler(); });，但前面已有App::singleton(Handler::class, V1Handler::class)，V1 实例早已被缓存，V2 永远不会被用到 - 即使你在中间件或控制器里动态调用
App::bind()，也只影响下一次解析——而当前请求中，该接口很可能已被其他类提前依赖注入过了 -
app(Handler::class)和resolve(Handler::class)都走同一缓存，无法绕过
用 bindIf() + 自定义解析逻辑替代硬绑定
Laravel 6 原生不提供 bindIf()，但你可以自己封装一个带条件的工厂闭包，把判断逻辑下沉到实例创建那一刻，而不是绑定时刻。
- 在
AppServiceProvider::register()中注册接口，绑定一个闭包，里面做运行时判断：
App::bind(Handler::class, function ($app) {
$type = $app->make('request')->input('handler_type', 'v1');
return match($type) {
'v2' => new V2Handler(),
default => new V1Handler(),
};
});
- 这样每次解析
Handler::class都会重新执行闭包，拿到真实请求上下文 - 避免使用
App::singleton()，改用App::bind()，否则闭包只执行一次 - 如果判断依据来自配置或环境变量，用
config('app.handler_version')替代 request 输入
更稳妥：用策略 Manager 替代接口直绑
对多实现切换频繁的场景（如支付网关、日志处理器），Laravel 6 官方推荐用 Illuminate\Support\Manager，它天然支持驱动名 + 运行时切换，且不依赖容器单例缓存。
- 定义统一接口
PaymentGateway，继承Manager的子类PaymentManager - 在
config/payment.php中配置'default' => env('PAYMENT_DRIVER', 'alipay') - 调用
app('payment')->driver('wechat')可随时切换，且每次返回新实例，无缓存干扰 - 比手动 bind 更清晰，也更容易测试和 mock
容易忽略的坑：构造函数参数和依赖注入顺序
即便你成功切换了实现类，如果它的构造函数依赖另一个已被单例缓存的服务（比如 LoggerInterface），而该服务在切换前就被解析过，那新实例拿到的仍是旧 Logger 实例。
- 不要在实现类构造函数里强依赖其他可能被提前解析的服务
- 改用 setter 注入或方法参数传入，把依赖延迟到真正使用时
- 或者确保所有相关服务都用
bind()而非singleton()，保持一致性
真正复杂的地方不在“怎么写条件”，而在“谁先被解析、谁被缓存、谁又被复用”——Laravel 6 的容器行为是隐式的，得靠 php artisan tinker 里反复 app()->resolved() 和 app()->hasBeenResolved() 来验证实际状态。
