ThinkPHP中容器(Container)应用在不同版本间的差异对比

我们先来看一个核心对比：ThinkPHP 5.1 的容器（Container）不支持接口自动绑定，也没有 `bind()` 方法，只能靠手动 `set()` 或工厂闭包模拟；到了 6.0+，底层换用了 `league/container`，支持 `bind()` 和类型自动解析，但 6.0.0 到 6.2 需要显式启用，6.3 之后推荐用 `invokeClass()`。升级后注册时机必须改用 `provider.php`，多进程下要避免用 `set()` 存储请求级数据，改用闭包绑定或上下文隔离。这几个差异，踩坑的人不少，下面拆开说。

ThinkPHP 5.1 的 Container 不支持自动绑定接口到实现类

5.1 的容器走的是轻量路线——只负责对象实例化和简单依赖注入，没有内置接口绑定机制。你要是照着 6.x 的文档写 $container->bind('CacheInterface', 'RedisCache')，直接报错：Call to undefined method think\Container::bind()。这个坑很常见：照着新版本的习惯写旧版本代码，结果一跑就崩。

实际解决方案只有两条路：手动用 set() 存具体对象，或者构造时传参。但 set() 只能存实例或闭包，没法声明“下次 get('X') 时返回 Y 类实例”这种契约关系。如果想模拟绑定效果，得自己包一层工厂闭包：

$container->set('CacheInterface', function() {
    return new RedisCache();
});

另外，5.1 的 make() 不解析类型提示中的接口，只认类名字符串。所以控制器里写 public function index(CacheInterface $cache) 是行不通的，会直接失败。

ThinkPHP 6.0+ 的 Container 默认启用接口绑定与延迟解析

到了 6.0，容器底层改用了 league/container 兼容层，bind() 和 when()->needs()->give() 都能用，还可以在 app/provider.php 里集中注册。但这里有个细节：6.0.0 到 6.2 的绑定行为有细微差别——6.0 默认不启用反射自动解析（也就是不看构造函数参数的类型），必须显式调用 resolve() 或开启 Container::getInstance()->setInvokeClass(true) 才能生效。

• 6.0+ 中 bind('LoggerInterface', FileLogger::class) 之后，$container->get('LoggerInterface') 就能正确返回实例了
• 但如果你用 make() 实例化一个带接口类型提示的类，6.0.0 默认会抛 InvalidArgumentException：“Cannot resolve type-hinted parameter”，6.1+ 才默认开启自动解析
• 6.3+ 引入了 Container::getInstance()->invokeClass() 来替代旧方式，目的是避免全局状态污染

从 TP5.1 升级到 TP6 后 Container 注册时机错乱

5.1 时代，大家习惯在 common.php 或中间件里手动调用 Container::get()->set() 来注册服务。但 TP6 要求统一走 provider.php 或服务提供者类的 register() 方法。如果还按老习惯在 common.php 里操作容器，大概率会遇到“服务未注册就已被调用”的问题——比如模型初始化时依赖的 Db 还没绑定。

• TP6 的容器在 App::initialize() 阶段才加载 provider.php，在此之前任何对 Container::get() 的调用都拿到的是空容器
• 所以不要在配置文件、路由定义或者 base_controller 的构造函数里提前 get() 自定义服务
• 如果确实需要早期注册，改用 think\facade\App::beforeStart() 回调，确保在容器初始化后、请求分发前执行

Container::getInstance() 在多进程/协程下共享导致状态污染

TP6 默认使用单例 Container::getInstance()，在 Swoole 或 Workerman 环境中，子进程或协程会复用父进程的容器实例。这时候如果用了 set() 存临时对象，就会跨请求残留：比如一次请求里 set('user', $user1)，下一次请求可能意外拿到 $user1 而不是新实例。

这不是 Bug，而是设计如此——容器本身不负责生命周期隔离。正确的做法是：别往容器里塞请求级数据。

• 永远不要用 set() 存储用户 Session、Request、Response 这类每次请求唯一的对象
• 需要动态值？改用闭包绑定：$container->bind('CurrentUser', function() { return app('auth')->user(); });
• 在协程场景下，可以配合 Co::getContext() 做上下文隔离，但不要覆盖全局容器实例

容器不是万能胶，接口绑定能力、注册时机、生命周期边界——每个版本都在悄然调整那条线。踩坑往往不是因为不会写，而是没看清当前版本到底封死了哪条路、又在哪开了扇侧门。