应仅在需整个请求生命周期内共享同一实例且实例无状态或状态可安全复用时使用singleton()，典型场景包括数据库连接、monolog日志器、纯函数式yamlparser等。
Laravel 容器的单例绑定（singleton()）本身不慢，但滥用或误用会导致内存膨胀、初始化时机失控、测试困难，甚至掩盖服务依赖的真实生命周期。
什么时候该用 singleton()？
singleton()？只在明确需要「整个请求生命周期内共享同一实例」且该实例**无状态或状态可安全复用**时才用。典型场景包括：
- 数据库连接类（如
PDO实例，Laravel 默认已 singleton 绑定db.connection） - 日志处理器（如
Monolog\Logger，只要不写入线程/协程不安全的资源） - 配置驱动的工具类（如解析 YAML 的
YamlParser，纯函数式无副作用）
别为了“省一次 new”就绑 singleton —— 普通对象（bind() 或 instance()）开销极低，而 singleton 会常驻内存直到请求结束。
singleton() 和 instance() 的关键区别
singleton() 和 instance() 的关键区别两者都返回同一个实例，但行为完全不同：
-
singleton()：每次 resolve 时检查是否已创建，未创建则执行回调并缓存结果；适合带构造逻辑的服务 -
instance()：直接把传入的对象存进容器，不做任何延迟初始化；适合你已经 new 好、确定要复用的实例
错误用法：$app->singleton('foo', new Foo()); —— 这会让 Foo 在容器注册阶段就被实例化，且无法被 App::make() 的参数覆盖。正确写法是用 instance()，或把 new 放进闭包里：$app->singleton('foo', fn() => new Foo());
容易踩的坑：循环依赖 + 单例初始化失败
当 A 依赖 B，B 又在 singleton 回调里依赖 A，容器会卡死或抛出 BindingResolutionException。Laravel 不做循环检测，只靠 resolve 栈深度报错（如 “Maximum function nesting level”）。
- 现象：本地开发正常，上线后偶发 500，日志里出现
Target [App\Services\X] is not instantiable或栈溢出 - 排查方法：在
AppServiceProvider::register()中加dd($this->app->getBindings())看绑定顺序；用php artisan tinker手动app()->make('xxx')触发验证 - 修复原则：拆分构造逻辑，把运行时才需的依赖改用
app()->make()延迟获取，而非构造器注入
高频单例服务的性能敏感点
真正影响性能的不是 singleton 本身，而是它背后初始化动作的代价。比如：
- 一个 singleton 绑定的 HTTP 客户端，在回调里做了同步 DNS 查询或 TLS 握手 —— 首次 resolve 就卡几百毫秒
- 一个 singleton 缓存了全量 Redis key 列表（
KEYS *），每次请求都触发 - 第三方 SDK 的 singleton 初始化加载了大文件或反射全类库（如某些旧版 AWS SDK）
解决方式不是删 singleton，而是把重操作移到真正使用时（用 lazy() 包装，或改用 request-scoped 绑定 + cache() 层级缓存）。
最常被忽略的一点：singleton 实例不会自动销毁，也不会响应 app()->forgetInstance()（除非手动调用）。如果你在中间件或命令中临时替换了某个 singleton，记得清理，否则后续请求可能拿到脏状态。
