laravel 6 的 singleton 在 swoole/octane 常驻内存模型中会导致状态污染，因单例跨请求存活且保存请求相关状态；scoped() 是 laravel 9.2+ 特性，laravel 6 不支持，需手动模拟请求级生命周期管理。
为什么 Laravel 6 的 singleton 会导致状态乱？
因为 singleton() 在 FPM 下每次请求都新建进程，看似安全；但在 Swoole 或 Laravel Octane 等常驻内存模型中，单例实例跨请求存活，而你没意识到它内部保存了请求相关状态（比如当前用户、请求 ID、临时缓存数组）。结果就是：请求 A 写入 $this->currentUserId = 123，请求 B 调用时读到的还是 123 —— 不是“复用”，是“污染”。
这不是 Laravel 6 特有 bug，而是所有长生命周期运行时共有的陷阱。Laravel 6 官方不支持 Swoole，但很多人手动集成，又沿用传统单例写法，问题立刻暴露。
scoped() 是什么？它真能替代 singleton 吗？
scoped() 是 Laravel 9.2+ 引入的绑定方式，Laravel 6 原生不支持。所以直接回答：不能用 —— 你执行 $this->app->scoped(...) 会报 Call to undefined method 错误。
但你可以模拟它的语义：在每次请求开始时（如中间件或事件监听器里）手动创建并绑定一次实例，在请求结束时清理。关键不是函数名，而是“请求生命周期内唯一 + 请求结束即失效”这个行为模式。
常见误操作：
- 在 register() 里用 singleton() 绑定一个带可变属性的类 → 错
- 试图用静态变量或全局数组自己实现“每请求一实例” → 错（Swoole 下仍跨请求）
- 把 scoped 当成 magic fix，以为加个词就自动隔离 → 错（它只是容器原生支持的语法糖）
在 Laravel 6 中如何安全实现“请求级单例”？
必须放弃“全局单例”思维，转为“请求内单例 + 显式生命周期管理”。推荐路径：
- 在
AppServiceProvider::boot()中监听Illuminate\Foundation\Http\Events\RequestHandled事件，用于清理（注意：别在register()里监听，事件 dispatcher 还没 ready） - 用中间件在请求入口处调用
$this->app->instance()注入新实例，确保每次都是干净对象 - 避免在服务类内部用
static $cache或public $state存请求数据；改用request()->attributes->set()或注入Request实例来挂载 - 如果该服务被多个地方依赖，统一从容器取：用
app(MyService::class)，但前提是它已在中间件里被instance()绑定过
示例（中间件片段）：
public function handle($request, Closure $next)
{
$service = new MyService();
$service->setRequestId($request->id()); // 假设它需要请求上下文
$this->app->instance(MyService::class, $service);
<pre class="brush:php;toolbar:false;"><code>return $next($request);</code>}
最容易被忽略的兼容性坑
Laravel 6 的容器没有自动清理机制。你用 instance() 绑定后，如果不手动清理，下个请求进来时 make() 仍会返回上个请求的实例 —— 因为 instance() 是硬塞，容器不会覆盖，也不会感知请求边界。
所以必须配对使用：
- 入口：中间件里 instance()
- 出口：事件监听里 forgetInstance()（注意不是 flush()，后者清空全部）
另外，队列任务、Artisan 命令、单元测试这些非 HTTP 场景，根本没有“请求生命周期”概念，scoped 模拟逻辑完全不适用。此时要么改用 bind()，要么显式传参，别假装有请求上下文。
