laravel 6 中 singleton() 通过容器缓存保障单例，须在 register() 中绑定，支持类、接口映射及闭包构造，验证需用 === 判断同一引用，适用于连接类/资源持有者，无状态对象应避免使用。
Laravel 6 的服务容器中，singleton() 方法就是专为“只实例化一次”而设计的。它不是靠手动控制或加锁实现，而是由容器内部缓存机制保障：首次调用 app()->make() 时执行构造逻辑并存入实例缓存，之后所有调用都直接返回这个已创建的对象。
在服务提供者中正确注册单例
必须在 AppServiceProvider（或其他自定义服务提供者）的 register() 方法里绑定，不能放在 boot() 中——因为容器依赖解析可能已在 boot() 前启动，延迟绑定会导致失效。
- 绑定具体类：
$this->app->singleton('App\Services\CacheClient', 'App\Services\RedisCache'); - 绑定接口到实现：
$this->app->singleton(CacheInterface::class, RedisCache::class); - 使用闭包灵活构造：
$this->app->singleton(LoggerInterface::class, function ($app) { return new FileLogger(storage_path('logs/app.log')); });
验证是否真正单例
运行时可简单断言两个实例是否完全相等：
$a = app(CacheInterface::class);$b = app(CacheInterface::class);var_dump($a === $b); // 必须输出 true
注意：用 == 不够严谨，必须用全等 === 判断是否同一对象引用。
哪些场景必须用 singleton()
凡是内部持有资源、状态或连接的类，都应强制单例，否则会引发严重问题：
- 数据库连接器（重复 new 导致连接池耗尽）
- Redis/HTTP 客户端（每个实例独占连接）
- 日志处理器（避免多个文件句柄冲突或写乱序）
- 配置管理器（确保 config() 全局一致）
反例：DTO、表单请求类、策略类这类无状态轻量对象，用 bind() 更合适。
常见陷阱与规避
- 闭包里不要做耗时操作（如读大配置文件），否则每次
make()都会卡住 - 单元测试中若修改了 singleton 实例的状态，需主动清理：
app()->forgetInstance(CacheInterface::class); - 别对同一抽象先
instance()后singleton()——后者不会覆盖前者，make()仍返回你硬塞的实例
