要厘清 Laravel 中“单例”的真正含义，关键在于区分 “单例模式（Singleton Pattern）” 的经典定义 与 Laravel 服务容器中“singleton 绑定” 的实际语义——它们相关，但不是同一层次的概念。

---

一、核心结论（先说答案）

• ✅ App 实例（即 Container）在单个 HTTP 请求生命周期内是单例：整个请求过程中，全局只有一个容器实例（可通过 app() 或 \App 访问）。
• ❌ 但它不是传统 GoF 意义上的“全局单例”（如 MyClass::getInstance() 那种跨请求、跨进程的单例）。
• ✅ 容器中的 singleton() 绑定：在单次请求内，某服务只被创建一次，后续解析返回同一实例。
• 🔄 每个 HTTP 请求都会创建一个全新的 Application 实例：这是 PHP-FPM / CLI 的进程模型决定的，不是 Laravel 的设计缺陷，而是 Web 应用的天然属性。

换句话说：“单例”是请求作用域内的单例，而非应用全局的单例。

---

二、为什么 Web 应用中每个请求都有新容器？

这是由 PHP 的共享-nothing 架构决定的：

• 在 FPM 模式下，每个 HTTP 请求由一个独立的 PHP-FPM worker 进程处理；
• 每个进程从头执行 public/index.php，重新创建 Application 实例；
• 请求结束，进程释放内存，所有对象（包括容器）销毁；
• 下一个请求 = 全新进程 = 全新容器。

这与 Java/Node.js 等常驻内存的应用服务器模型根本不同。

✅ 这是 PHP Web 应用的标准行为，Laravel 并未改变它。

---

三、那为什么还说容器是“单例”？

这里的“单例”有两层含义：

1. 容器自身在请求内是单例

在单次请求中：

$app1 = app();          // Illuminate\Foundation\Application
$app2 = \App;           // 同一个实例
$app3 = Container::getInstance(); // 仍然是同一个

var_dump($app1 === $app2); // true

• Laravel 在 bootstrap/app.php 中创建 $app 后，会调用 $app->instance(Container::class, $app) 并设为全局单例（通过 Container::setInstance($app)）；
• 所有后续 app()、resolve()、Facades 都指向这同一个实例。

→ 在请求上下文中，容器是单例的。

2. 容器管理的服务可以是“请求作用域单例”

当注册一个服务：

$app->singleton(MyService::class, function () {
    return new MyService();
});

• 在本次请求中，无论多少次 app(MyService::class)，都返回同一个实例；
• 但在下一次请求中，会重新创建一个新实例。

→ 这不是 GoF 单例（跨请求），而是 “请求作用域单例（Request-Scoped Singleton）”。

---

四、与传统 GoF 单例模式的关键区别

特性	传统 GoF 单例（PHP 实现）	Laravel 的 singleton() 绑定
生命周期	跨请求、跨进程（只要 PHP 进程不退出）	仅限单次 HTTP 请求
实现方式	static $instance; private __construct(); public static getInstance()	由容器管理，通过 bind()/singleton() 注册
可测试性	极差（静态方法，无法 Mock）	极好（可通过容器重绑定 Mock）
全局状态风险	高（状态在请求间残留）	低（请求结束自动销毁）
是否推荐	❌ 在 Web 应用中通常避免	✅ 是 Laravel 的标准用法

📌 Laravel 刻意避免传统静态单例，而是用容器提供“受控的、作用域明确的单例行为”。

---

五、为什么这种设计是合理的？

1. 符合 PHP Web 模型：每个请求干净启动，无状态残留，天然隔离；
2. 保证可测试性：测试用例之间不会因单例状态互相污染；
3. 避免内存泄漏：请求结束自动释放，无需手动清理；
4. 仍满足“请求内共享”需求：如数据库连接、日志器、配置等，在单次请求中只需一个实例，避免重复创建开销。

---

六、特殊场景：常驻进程（如 Swoole、Workerman）

在 Swoole 等常驻内存的 PHP 环境中，一个 Worker 进程会处理多个请求，此时：

• 如果直接复用 Laravel 容器，会导致 跨请求状态污染（如用户认证信息残留）；
• 解决方案：每个请求创建新的容器实例（或清理容器状态），模拟传统 FPM 行为。

这反而证明了 Laravel 的设计是正确的：“单例”应限定在请求作用域内。

---

总结

问题	答案
Laravel 的 App 是单例吗？	在单个 HTTP 请求生命周期内是单例，但每个请求都有全新实例。
为什么每个请求都新建容器？	这是 PHP 共享-nothing 架构的自然结果，不是 Laravel 的选择，而是 Web PHP 的本质。
singleton() 绑定是单例吗？	是 请求作用域内的单例，非全局单例，且完全可测试。
是否使用了传统单例模式？	否。Laravel 用容器管理生命周期，避免静态单例的弊端。

正如所理解的：Laravel 的“单例”是工程实践的产物，而非对 GoF 模式的教条遵循。它在“请求隔离”与“性能优化”之间取得了精妙平衡，这才是其架构成熟度的体现。