swoole中全局变量跨请求持续存在，导致数据污染和内存泄漏；应避免用global/static存储请求数据，改用请求上下文对象、swoole\table或redis等进程外存储。
传统 PHP-FPM 下的 $GLOBALS、global 变量、static 属性，请求结束就销毁；Swoole 中它们会跨请求持续存在，且在同一个 Worker 进程内被所有后续请求复用——这是最常引发数据污染和内存泄漏的根源。
Worker 进程内全局变量不会自动重置
在 Swoole 的 onRequest 或 onReceive 回调里声明 global $counter 或修改 static::$list[]，该变量不会在请求结束后清空。下一个请求进来时，它仍带着上一次的值。
- 典型现象：计数器越加越大、数组不断追加、对象状态残留（如 Redis 实例已执行过
select(2)，后续请求全连错 DB） - 验证方式：启动单 Worker（
'worker_num' => 1），连续 curl 同一接口，观察输出是否累积 - 根本原因：PHP 生命周期由 Swoole 控制，不是每次请求都重建 Zend VM，而是复用进程上下文
不同 Worker 进程间全局变量相互隔离
global $config 在 Worker A 里改了，在 Worker B 里读不到——这不是 bug，是设计使然。Swoole 的多进程模型天然隔离内存空间。
- 常见误用：试图用全局变量做“跨请求共享配置”，却没意识到它只在当前 Worker 内有效
- 正确做法：配置应在
onWorkerStart中加载并绑定到$server->setting或使用Swoole\Table/Redis等进程外存储 - 注意：
$_SERVER、$_GET等超全局变量在 Task 进程中不可用，因为 Task 是独立子进程，不继承 Worker 的符号表
协程内 global 变量仍是进程级共享
即使启用协程（Swoole\Runtime::enableCoroutine()），global $flag 依然属于所在 Worker 进程，而非协程私有。100 个并发协程写同一个 global，结果不可预测。
- 错误写法：
go(function() { global $cache; $cache = fetchData(); });—— 多个协程同时覆盖，最后只保留一个值 - 安全替代：用
use ($data)显式传参，或为每个协程分配独立对象实例 - 协程安全的共享方案：用
Swoole\Coroutine\Channel（需设足够容量）、Swoole\Coroutine\WaitGroup，或Swoole\Table做轻量级进程间通信
如何安全地模拟“请求级全局”
没有真正的“请求级全局变量”，但可以靠结构约束逼近语义。关键不是禁止用 global，而是切断跨请求副作用链。
- 禁用
static数组累加：改用函数局部变量，或每次请求显式unset($var) - 避免单例持有可变状态：把
Redis、MySQL客户端封装进请求上下文对象，构造时传入连接池实例 - 利用
max_request保底：设置'max_request' => 5000，强制 Worker 进程定期重启，释放顽固内存（仅作兜底，不能替代代码修复） - 调试技巧：在
onWorkerStart注册register_shutdown_function，打印get_defined_vars()中可疑全局，快速定位残留变量
真正难处理的不是语法层面的 global，而是那些你以为“只是读一下”的静态配置对象，实际内部缓存了连接、修改了状态，又没重置逻辑——这种隐式共享，比明面上的 $GLOBALS 更容易漏掉。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
