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 版本的 Container 是个轻量级服务容器，核心只做对象实例化和依赖注入，不内置接口绑定机制。你写 $container->bind('CacheInterface', 'RedisCache') 是无效的——它根本没这个方法，会直接报 Call to undefined method think\Container::bind()。
常见错误是照着 6.x 文档写绑定逻辑，结果在 5.1 下跑不通；实际得靠手动 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 开始，Container 底层改用 league/container 兼容层，bind() 和 when()->needs()->give() 都可用，且支持在 app/provider.php 中集中注册。
但注意：6.0.0 到 6.2 的绑定行为有细微差别——6.0 默认不启用反射自动解析（即不看构造函数参数类型），必须显式调用 resolve() 或开启 Container::getInstance()->setInvokeClass(true) 才能生效。
立即学习“PHP免费学习笔记（深入）”；
- 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()做上下文隔离，但不要覆盖全局容器实例
