在Swoole协程环境下，传统单例模式因static变量常驻内存且被所有协程共享，导致跨请求数据污染、内存泄漏与并发错乱；根本原因是类静态属性等同于进程级全局变量，而非协程级隔离变量。
在 Swoole 协程环境下，直接复用传统 PHP 单例模式会引发数据污染、内存泄漏、并发错乱——这不是代码写得不够“规范”，而是模型本身与常驻内存 + 协程共享上下文的运行机制冲突。
协程中单例实例为何会跨请求污染
PHP-FPM 下每次请求都是全新进程，static $instance 生命周期仅限于单次请求；而 Swoole Worker 进程常驻，static 变量会持续存在，且被所有协程共享。一旦某个协程修改了单例状态（比如缓存了用户 ID、连接句柄、临时配置），后续任意协程都可能读到脏数据。
- 典型现象：
Database::getInstance()->setConnection($conn)被协程 A 设置后，协程 B 未初始化就直接调用query()，却复用了 A 的连接和事务状态 - 更隐蔽的是：日志单例若缓存了 trace_id，多个并发请求会混写到同一条日志行
- 根本原因：Swoole 中「类静态属性 = 进程级全局变量」，不是「协程级隔离变量」
Co\Channel 或 Coroutine\Run 怎么替代全局单例
真正安全的做法是放弃“全局唯一”，转为“协程内唯一”或“按需获取”。Swoole 提供了原生协程上下文支持，无需自己造轮子。
- 用
Co\Channel做轻量级协程本地存储：每个协程初始化时$chan = new Co\Channel(1)，$chan->push($db)，其他地方$chan->pop()获取，天然隔离 - 更推荐用
Co\run()+ 闭包参数传递：把依赖显式传入协程函数体，避免任何静态状态，例如go(fn() => handleOrder($db, $logger)) - 若必须保留“单例感”，可用
Swoole\Coroutine::getuid()作为 key 构建协程局部缓存数组，但注意别让该数组本身成为静态变量
think-swoole 或 hyperf-skeleton 中的容器陷阱
框架封装的 DI 容器（如 Hyperf 的 Container）默认行为仍是进程级单例，除非你主动开启协程隔离。很多人以为“用了容器就安全了”，其实不然。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- Hyperf 默认
make()返回的是共享实例；要协程隔离，必须显式声明@Inject注解加shared=false，或使用make($class, [], true)第三个参数强制非共享 - Think-Swoole 的
app()在协程中仍返回同一实例，app()->bind('logger', fn() => new Logger())不等于每次调用都新建——它只在首次make()时执行闭包 - 检查方法：在两个并发协程中分别
var_dump(spl_object_id(app('db')))，ID 相同即为共享，不同才说明隔离生效
协程栈与静态变量的内存泄漏组合拳
最危险的不是单例本身，而是单例内部持有长生命周期资源（如 PDO 对象、文件句柄、大数组），又没做协程退出清理。Swoole 不会自动回收协程中创建的静态引用，尤其当单例被闭包捕获时。
例如：class ConfigLoader { private static $cache = []; public static function load($file) { self::$cache[$file] = parse_ini_file($file); } } —— 每次请求都往 self::$cache 里塞新内容，Worker 运行一小时，内存就涨一小时。这不是 bug，是设计误用。
真正需要记住的只有一条：在 Swoole 协程里，**没有“请求结束就自动销毁”的侥幸**。所有静态、全局、闭包引用，都得你亲手管住生命周期。
