thinkphp 6.0 容器绑定作用域受限，bind() 仅在当前容器实例生效，需在服务提供者 register() 中用 $this->app->bind() 显式绑定接口与实现，并启用 container_bind 配置以支持构造函数注入。
ThinkPHP 6.0 的容器绑定方式变了，bind() 不再全局生效
TP6 把容器从“单例+静态代理”改成了更标准的 PSR-11 实现，bind() 只在当前容器实例内有效，不再影响全局容器。如果你在 common.php 或服务提供者里写 Container::getInstance()->bind(...)，控制器或中间件里用 app()->make() 拿不到你绑的对象。
- 必须在服务提供者（
AppServiceProvider）的register()方法里绑定，且用$this->app->bind()，不是静态调用 - 接口绑定需显式声明契约，比如
bind(\think\cache\CacheInterface::class, \think\cache\Driver::class)，不能只绑实现类 - 原来 TP5.1 里直接
app('xxx')获取自定义绑定名的方式，在 TP6 中默认不支持，得先bind('xxx', XxxService::class)再app()->make('xxx')
控制器构造函数注入失效？检查是否启用了 __construct 自动解析
TP6 默认关闭了控制器构造函数的自动依赖注入，除非你在配置里显式开启 container_bind 或手动注册控制器到容器。否则即使写了 public function __construct(UserService $service)，也会报 ReflectionException: Class UserService does not exist。
- 确保
config/app.php中'container_bind' => true（默认是false） - 若使用注解路由或手动实例化控制器，必须通过
app()->controller()而非new，否则注入不触发 - 构造函数参数类型必须是已绑定到容器的类或接口；未绑定的类（如普通工具类）会直接报错，不能靠自动实例化兜底
app() 和 think\Container::getInstance() 不再等价
TP6 中 app() 返回的是请求生命周期内的应用实例（继承自 think\App），它内部持有一个独立容器；而 think\Container::getInstance() 拿到的是底层基础容器，两者绑定的数据互不影响。混用会导致“明明 bind 了却 make 不出来”的问题。
- 统一用
app()获取容器：如app()->bind(...)、app()->make(...) - 避免在中间件或事件监听器里用静态容器方法操作绑定，它们可能运行在不同容器上下文中
- 单元测试中若手动 new App，记得调用
$app->initialize()，否则容器未加载服务提供者
命令行指令和定时任务里的容器上下文容易丢失
TP6 的命令行指令（think xxx）和定时任务（crontab）默认不加载 HTTP 相关服务提供者，比如 Request、Response、Session 绑定不会自动注册。如果你在命令里调用 app()->make('request')，会提示类未绑定。
- 在自定义指令的
configure()或handle()开头加app()->bindIf('request', \think\Request::class, true) - 定时任务逻辑尽量封装成服务类，通过
app()->make(MyTaskService::class)->run()调用，别在command类里硬写业务 - 注意
app()->isConsole()判断场景，避免在命令行中误用input()或cookie()等 HTTP 特有方法
重构时最容易被忽略的是服务提供者的加载顺序和容器作用域隔离——TP6 的容器不是“一处绑定，处处可用”，而是按生命周期分层。哪怕只是迁移一个 bind()，也得看清楚它在哪个容器里、由谁初始化、在哪个阶段被访问。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
