container::getinstance() 返回全局单例容器，不自动隔离请求上下文；多请求场景下需用 app() 或框架注入的容器实例确保请求级隔离，避免数据污染和内存泄漏。
ThinkPHP 中 Container::getInstance() 返回的是单例容器，但不等于当前请求上下文容器
直接调用 Container::getInstance() 拿到的确实是全局容器实例，但它在多请求场景（如 CLI 多次执行、Swoole 长连接、协程）下**不会自动隔离**。你以为的“当前容器”可能还是上一次请求残留的绑定或实例，尤其当你在中间件、命令行或异步任务里反复调用时。
真正需要“当前请求容器”时，得依赖框架生命周期注入点：
- 在控制器方法中，优先用构造函数或
__invoke注入：public function index(ContainerInterface $container) { ... } - 在中间件中，从
$request或$response的属性间接获取（TP6.1+）：$container = $request->getContainer() ?: Container::getInstance();
- 在命令行命令类中，
$this->app就是当前请求绑定的容器（继承自think\console\Command）
为什么不能无脑用 Container::getInstance() 绑定运行时服务？
因为 Container::getInstance() 是静态单例，所有地方共享同一份绑定表。如果你在某个请求中执行了：
Container::getInstance()->bind('Db', MyCustomDb::class);那后续所有请求都会拿到这个 MyCustomDb，哪怕它带了上一个用户的连接配置或缓存状态。
更危险的是，在 Swoole 环境下，这种绑定会跨请求持久化，造成数据污染或内存泄漏。
正确做法是：
- 用
$this->app->bind()（在控制器/命令中）—— 它指向当前请求容器（TP6 默认已做请求级代理） - 用
app()->bind()—— 这个函数内部会优先返回请求容器， fallback 到静态实例 - 避免在中间件或事件监听器里直接调
Container::getInstance()->bind()
如何判断你拿到的容器是否具备请求隔离能力？
最简单的验证方式是检查容器 ID：
var_dump(spl_object_id(Container::getInstance())); // 始终不变 var_dump(spl_object_id(app())); // 每次 HTTP 请求都不同（TP6.0+）
如果两个 ID 一致，说明你还在用全局单例；如果不一致，说明 app() 已被框架重置为当前请求容器。
注意：CLI 模式下 app() 默认不重置，除非你手动调用了 App::newApp() 或启用了命令行请求隔离（TP6.3+ 的 --isolated 参数）。
另外，app('request') 能取到当前请求对象，而 Container::getInstance()->get('request') 可能取不到或取到旧实例 —— 这就是隔离失效的明显信号。
tp6.3+ 的 app() 函数和 Container::getInstance() 差在哪？
app() 不再只是 Container::getInstance() 的别名。从 TP6.3 开始，它默认走 think\App::instance()，该方法会检查当前是否处于请求上下文中，并返回对应作用域的容器实例。
所以实际开发中：
- 一律用
app()替代Container::getInstance() - 需要强类型提示时，用
think\ContainerInterface类型约束参数，而非think\Container - 如果必须用静态访问（比如在工具类静态方法里），先判断：
return method_exists(App::class, 'instance') ? App::instance() : Container::getInstance();
没做这层判断的旧代码，在 Swoole 或 Hyperf 兼容层里最容易出问题 —— 容器里塞进去的 Request、Config 实例全变成“幽灵引用”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
