ThinkPHP 6.1+ 中 bind() 不再自动单例，需改用 singleton()；接口绑定须用字符串键名；闭包内避免直接调用 config()/env()；register() 中禁用 make()，改用 boot() 初始化。
服务容器 bind() 和 singleton() 的行为差异
升级到 ThinkPHP 6.1+ 后，bind() 不再自动注册为单例，这是最常引发“对象重复创建”或“状态丢失”的根源。比如你绑定了一个带初始化逻辑的连接类，用 bind() 后每次 app()->get() 都新建实例，而旧版默认是单例。
实操建议：
- 明确需要单例行为时，直接改用
singleton()替代bind() -
bind()仅用于接口绑定（如bind('CacheInterface', 'RedisCache')），且需配合app()->make()使用 - 若仍用
bind()绑定具体类，记得手动加app()->instance()注册实例，否则无法复用
依赖注入中 constructor 参数解析失败
升级后 app()->invoke() 或控制器方法自动注入时，若类构造函数参数类型提示含接口但未在容器中绑定实现，会直接报错 ReflectionException: Class xxx does not exist，而不是静默 fallback。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 控制器里写了
public function index(CacheInterface $cache)，但没在provider.php中绑定CacheInterface - 使用
bind()但写成bind('CacheInterface', RedisCache::class)（缺引号）导致字符串解析失败
实操建议：
- 所有接口绑定必须用字符串键名，如
bind('CacheInterface', 'app\common\cache\RedisCache') - 推荐统一在
app/provider.php中集中管理，避免分散bind()调用 - 调试时可用
app()->has('CacheInterface')快速验证是否已注册
闭包绑定与延迟执行陷阱
以前用 bind('foo', function () { return new Foo(); }) 是安全的，升级后若该闭包内调用了尚未初始化的服务（如 config() 或 env()），会在首次 make() 时才执行并报错——此时上下文可能已销毁。
使用场景：
- 数据库连接工厂、日志驱动动态选择等依赖运行时配置的场景
- 第三方 SDK 实例化需读取
.env的情况
实操建议：
- 闭包内避免直接调用
config()、env()等全局函数；改用app()->make('config')或传入依赖 - 优先用
singleton()+ 类定义，而非闭包，更易测试和调试 - 必须用闭包时，在闭包头部加
if (!app()->initialized()) app()->initialize();防止环境未就绪
Provider 类 register() 方法执行时机变化
ThinkPHP 6.0.12+ 开始，register() 在容器构建完成前就被调用，这意味着你在 register() 里调用 app()->make() 可能拿到不完整实例，尤其涉及中间件、事件监听器等后期注册的服务。
性能影响：
- 过早调用
make()可能触发不必要的类加载和初始化，拖慢启动速度 - 某些服务（如
think\console\Command）在 CLI 模式下才可用，Web 请求中提前make()会报错
实操建议：
-
register()里只做绑定（bind()/singleton()），不做make()或实例操作 - 需要运行时初始化的逻辑，移到
boot()方法中，它在容器完全就绪后执行 - 不确定依赖是否可用时，用
app()->has('xxx') && app()->make('xxx')双重判断
最易被忽略的是：bind() 和 singleton() 在容器启动流程中的注册顺序会影响后续所有 make() 行为，不是写在哪都一样。尤其在多 Provider 场景下，先注册的 Provider 无法感知后注册的绑定——这点在迁移老项目时几乎必踩。
