结论：用 singleton() 绑定实现真正单例，bind() 默认每次新建实例；必须确保绑定名、绑定方式（singleton）、获取方式（make 同 key）三者严格一致，否则仍会重复实例化。
ThinkPHP 容器里怎么让类只实例化一次
直接说结论：用 bind() + singleton() 绑定，而不是 bind() + instance() 或反复 make()。容器默认每次 make() 都新建实例，不加控制就是“伪单例”。
常见错误现象是：在多个地方 make('UserService')，发现日志里构造函数执行了三次，数据库连接也开了三份——这不是单例，只是“名字统一”而已。
-
bind('UserService', UserService::class)只是绑定类名，没指定生命周期 - 要强制单例，必须显式调用
singleton('UserService', UserService::class) - 如果类已存在实例（比如通过
app()->make()获取过），再调singleton()不会覆盖，得先unbind() - 注意：控制器方法内多次
$this->app->make('UserService')，只要绑的是singleton，返回的就是同一个对象
服务提供者里注册单例的正确写法
在服务提供者 register() 方法中，别写 $this->app->bind(...) 就完事。bind 默认是“每次解析都新建”，和单例目标背道而驰。
使用场景很典型：数据库连接管理器、Redis 客户端、全局配置加载器——这些资源开销大，必须复用。
- 写法必须是：
$this->app->singleton('RedisClient', RedisClient::class) - 如果需要自定义初始化逻辑（比如带参数的构造），用闭包：
$this->app->singleton('ConfigLoader', function ($app) { return new ConfigLoader($app->config->get('app.env')); }) - 别在
boot()里注册单例，那时容器已冻结，singleton()会静默失败或触发异常 - 验证是否生效：在两个不同控制器里
dump($this->app->make('RedisClient') === $this->app->make('RedisClient'))，应输出true
为什么不用 static $instance 手写单例
手写 private static $instance 在 ThinkPHP 里容易出问题：容器无法接管依赖注入，构造函数参数（如 Connection、Cache）得自己手动传，破坏解耦；而且测试时无法 mock 替换。
更实际的坑是：命令行任务（php think hello）和 HTTP 请求共用同一个进程时，static 变量不会重置，但容器单例在 CLI 和 HTTP 之间其实是隔离的（取决于应用启动方式），反而更可控。
- 手写单例绕过了容器的自动注入，
__construct(Connection $conn)里的$conn得自己 new 或从容器取，容易漏 - 单元测试时，你没法用
$app->bind('RedisClient', MockRedis::class)覆盖它 - 容器单例支持延迟初始化（第一次
make才创建），手写 static 通常是类加载就初始化，可能浪费资源
单例失效的几个隐蔽原因
最常被忽略的是“绑定名不一致”：你在服务提供者绑了 singleton('cache.driver', RedisDriver::class)，结果在控制器里 make('RedisDriver')，这根本不是同一个 key，当然每次都新建。
另一个是接口绑定陷阱：绑了 singleton(CacheInterface::class, RedisDriver::class)，但代码里写 make(RedisDriver::class)，容器不认识这个类名作为标识符，又新建了。
- 务必统一用字符串 key，推荐用小写+点号分隔，比如
'cache.redis'，别混用类名和字符串 - 检查是否误用了
bind()替代singleton()，尤其从旧版 TP5 升级上来时，文档示例可能没更新 - CLI 模式下，某些扩展（如 Swoole 长连接）会让容器实例跨请求存活，此时单例可能比预期“活得更久”，需确认业务是否真的需要跨请求共享
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
