因为static变量在swoole协程中是进程级共享的，所有协程共用同一份内存地址，生命周期贯穿整个worker进程，非原子操作（如++）会导致覆盖，引发计数错乱、用户上下文污染等问题。
协程里static变量为什么会被多个协程改乱
因为static变量在Swoole协程中是进程级共享的，不是协程隔离的。它只初始化一次，生命周期贯穿整个Worker进程，所有协程共用同一份内存地址。哪怕两个协程同时调用同一个函数，static $counter 仍是同一个变量，$counter++ 这种非原子操作就会互相覆盖。
常见错误现象：
- 计数器输出跳变或重复（比如预期 1→2→3，实际输出 1→2→2）
- 用户上下文错乱（A协程写入的
static $userId被B协程读到） - 压测时偶发数据污染，本地单步调试却无法复现
static局部变量 vs 普通局部变量的行为差异
普通局部变量（如$local = 1）每个协程独有一份，协程挂起再恢复时值不变；而static $local表面写在函数内，实际存储在全局静态区，所有协程可见可改。
使用场景判断：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 需要缓存函数首次计算结果且结果与协程无关 → 可用
static（如配置解析） - 需保存请求/用户/事务相关状态 → 绝对不能用
static，必须换方案 - 多协程并发修改同一逻辑计数 → 必须用
Swoole\Atomic或加锁
替代static的协程安全方案怎么选
关键看你要的是“每个协程一份”还是“所有协程共享但安全”。前者用Co\Local或Context::get()，后者用Channel或Atomic。
实操建议：
- 替换
static $user：改用$ctx = Swoole\Context::get('user_id') ?? null，并在入口处Context::put('user_id', $uid) - 替换
static $cache（只读）：若内容不变，仍可用static，但要确保初始化阶段无竞态 - 替换
static $counter（读写）：直接换成$atomic = new Swoole\Atomic(0); $atomic->add(1) - 避免
global和类static属性：它们和函数static一样，都是协程不安全的共享点
协程切换时static变量的值到底会不会变
会变——不是因为协程切换本身改变它，而是其他协程在你挂起期间修改了它。例如协程A执行到co::sleep(1)前写了static $x = 10，挂起后协程B进来把$x改成20，等A恢复继续执行时读到的就是20，而非原来的10。
容易被忽略的地方：
- 即使没显式写
static，单例类的static $instance也一样危险 -
Co\Local和Context都依赖协程ID自动绑定，但Context支持defer回调，Co\Local不支持 - 启用
Swoole\Runtime::enableCoroutine()后，所有被Hook的I/O函数内部也可能用到static变量，务必检查第三方库源码
