tp5.1中bind仅绑定接口与类名/闭包，不注册实例，需singleton才实现单例；get不解析依赖，make才自动注入；tp6统一get/make行为，默认反射解析，未注册依赖则抛reflectionexception。
ThinkPHP 5.1 的 bind 和 singleton 行为差异
TP5.1 的服务容器默认不自动解析构造函数依赖，bind 只是绑定接口到类名或闭包，不注册实例；真正注册单例得用 singleton。很多人写 $container->bind('LoggerInterface', FileLogger::class) 后直接 $container->get('LoggerInterface')，结果抛出 ClassNotFoundException——因为没真正“装进去”，只是记了个映射关系。
实操建议：
-
bind适合做接口→实现类的软绑定，配合make使用（如$container->make('LoggerInterface')），它会尝试 new 实例并自动注入依赖 - 要确保每次 get 都返回同一实例，必须用
singleton('LoggerInterface', function() { return new FileLogger(); }) - TP5.1 中
get不触发自动构造注入，make才会；这是和 TP6 最明显的断裂点
ThinkPHP 6.0+ 的 think\Container 默认启用反射注入
TP6 把容器升级为独立组件 think\Container，get 和 make 行为统一，默认走反射解析构造参数。这意味着只要类存在、类型提示清晰，$container->get(MyService::class) 就能自动把 LoggerInterface 等依赖从容器里捞出来塞进去。
但坑就在这里：
- 如果某个依赖没在容器中注册（比如忘了
bind或singleton），TP6 会直接报ReflectionException: Class xxx does not exist，而不是安静地返回 null - TP6 不再支持
bind字符串键名直接用于get，必须先bind('logger', FileLogger::class)再get('logger')；而get(FileLogger::class)是另一条路径，走反射 - 闭包绑定时，TP6 要求闭包必须返回对象，不能返回原始值（如字符串），否则
get会失败
跨版本迁移时 app()->invoke 的兼容陷阱
很多老项目用 app()->invoke([$obj, 'method']) 做方法调用并自动注入参数。TP5.1 的 invoke 仅支持控制器方法风格（第一个参数是 Request），TP6 则全面支持任意方法签名，包括带接口类型提示的依赖。
迁移时要注意：
- TP5.1 中
invoke不解析非 Request 类型的参数，TP6 会尝试从容器取——若没配好，就崩 - TP6 的
invoke对闭包也生效，但闭包内不能用$this->app直接调用，得显式传入容器或改用think\Container::getInstance()->invoke() - 如果你在中间件或命令行中大量用
invoke，务必检查所有被调方法的参数类型是否已在容器中可解析
服务容器在 CLI 和 HTTP 请求中的生命周期区别
TP5.1 的容器在 CLI 下是单进程常驻，singleton 注册的对象整个脚本周期都复用；TP6 在 Swoole 或 Hyperf 场景下更激进，容器可能跨请求复用，导致状态污染。
典型问题：
- 在命令行中用
singleton绑定一个带属性的连接管理器，后续多个命令共享该实例，连接未关闭就可能复用失效句柄 - TP6 的
app()->clear()不清空 singleton 实例，只清普通绑定；真要重置得手动app()->forget('MyService') - HTTP 请求里看似安全的
bind，放到 Swoole 长连接中可能变成“全局共享”，尤其当绑定的是闭包且闭包捕获了 request 上下文时
最易被忽略的是：TP6 默认开启容器“热更新”开关（container.hot_reload），开发环境下每次请求都重建部分绑定，上线后关掉却没同步清理测试逻辑，导致行为不一致。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
