Laravel 6服务容器不支持多租户感知，singleton()实例常驻FPM进程易致租户数据串流；应改用instance()+显式重置，或传入Tenant参数由服务自主构造租户资源。
直接说结论：Laravel 6 的服务容器本身不支持“多租户感知”，app()->make() 拿到的实例默认是全局共享的，不会自动按租户切换。所谓“动态绑定”，本质是在请求生命周期内，用 singleton() 或 instance() 覆盖绑定，但必须手动控制时机和范围，否则极易污染后续请求。
为什么 bind() / singleton() 在多租户下会出问题
Laravel 6 的容器在 FPM 进程复用场景下，singleton() 绑定的实例一旦创建就常驻内存。如果中间件里写 $this->app->singleton(Repository::class, function () { return new TenantSpecificRepo(Tenant::current()); });，而 Tenant::current() 在下一个请求里没重置——这个 Repository 就会继续返回上一个租户的数据。
- 常见错误现象：
DB::connection('tenant_x')切换成功，但app(EmailService::class)->send()却发到了上个租户的 SMTP 配置里 - 根本原因：服务容器不感知 HTTP 请求边界，
singleton()实例生命周期远超单次请求 - 别指望
bind()能“每次新建就安全”——如果类内部持有了数据库连接或缓存句柄，反复 new 会导致连接池耗尽
真正可行的动态绑定方式：用 instance() + 显式重置
只在请求真正开始、租户上下文已确认后（比如租户中间件末尾），用 instance() 注入已初始化好的租户专属实例，并确保该实例所有依赖都已完成解析。
- 必须确保实例已 ready：
$repo = new OrderRepository(Tenant::current()->database); $repo->setCacheDriver(Tenant::current()->cache); $this->app->instance(OrderRepository::class, $repo); - 必须在每次请求入口重置：在中间件里调用
$this->app->forgetInstance(OrderRepository::class)，否则 FPM 复用时旧实例残留 - 不能对同一抽象混用：
instance()后再调singleton()不会覆盖，make()仍返回instance()注入的对象
更稳妥的替代方案：避免容器级动态绑定
与其在容器里折腾绑定时机，不如把租户上下文作为参数传入服务，让服务自己决定如何构造租户资源。这对 Laravel 6 更可控，也更容易测试。
- 把
Tenant当作普通依赖注入进服务构造函数，而不是靠容器自动解析：new ReportGenerator(Tenant::current()) - 用工厂类封装实例创建逻辑：
ReportFactory::forTenant(Tenant::current())->make()，内部统一处理连接、配置、缓存驱动 - 全局作用域 +
tenant_id字段仍是 Laravel 6 最稳定的数据隔离手段；服务容器动态绑定只适合极少数强状态服务（如租户专属 Redis 客户端）
最易被忽略的一点：Laravel 6 没有 scoped() 容器作用域，也没有请求级绑定钩子。所有“动态”都得靠开发者手动卡点、手动清理、手动验证——漏掉任何一个环节，租户数据就可能串流。
