【面试避坑】Swoole中常见的全局变量污染问题

Swoole 全局变量污染：一次说清，别再踩坑

我们先来算一笔账：如果你的 Swoole HTTP 服务跑了一段时间，突然发现请求数据对不上、内存一路飙升、或者接口返回了别人家的用户信息——别慌，这大概率不是 bug，而是全局变量污染。

核心结论很明确：在 Swoole 里，全局变量不会自动清空，不手动重置，就必然污染后续请求。这不是“可能发生”，而是“一定会发生”。

为什么 $GLOBALS 或 global $x 在 onRequest 里会跨请求残留

Worker 进程是常驻内存的，这意味着一件事情：$GLOBALS、global $x、static 属性这些 PHP 全局状态，不会像在 PHP-FPM 里那样随请求结束而销毁。协程切换时，它们仍然挂在进程堆上，下个请求一进来直接复用。

典型的现象是什么？

• $_SERVER['REQUEST_TIME_FLOAT'] 里存了上个请求的时间戳，本请求读出来比当前时间还早
• 更隐蔽的是 $_SESSION 或自定义的 $_CONTEXT 数组，被前序请求写入了用户 ID，后序请求没校验就直接用了
• 在 PHP-FPM 下安全的写法（比如 static $cache = []）在 Swoole 里就是埋雷，因为它根本不是每次请求都重新初始化

说到底，问题的根源就一句话：生命周期不一致。你以为变量是“请求级”的，但它实际上是“进程级”的。

类静态属性 self::$data 累加不重置的实操后果

静态属性同样绑定 Worker 进程，不是请求。一旦写入，除非你显式清空，否则它会越积越多，要么导致内存溢出，要么返回错乱的数据。

举个实际的例子：

• 错误写法：self::$userCache[$id] = Db::find($id)。到第 1000 次请求时，self::$userCache 里可能已经塞了上千条记录，而且混着不同租户的数据——这就是典型的跨租户泄漏
• 怎么排查呢？打个日志 count(self::$userCache)，你会发现数值持续上涨，而不是每次请求归零
• 一个常见的陷阱：别指望 unset(self::$userCache) 能解决问题，因为下次请求又触发静态变量声明 —— 但实际上 static 变量声明本身不会重执行，你拿到的还是原来的引用

这里的关键是：静态属性一旦被初始化，就一直在那里。你以为清空了，其实只是清空了内容，变量本身还在。

ThinkPHP 容器实例和 Request 对象如何被污染

TP 框架默认把 Request、Response 实例挂在 Container 和 static::$instance 上，Swoole 复用进程时这些对象不会重建，结果就是 header、query、post 数据串请求。

最常见的报错长什么样？

• Call to a member function param() on null——本质上是 app('request') 返回了上个请求残留的、已经被销毁的对象
• 很多人以为 $container->forget() 就能清理干净，实际上它只删了 binding 定义，并不会释放已经实例化的对象。你必须配合 $container->setInstances([]) 才能真正清理
• 但这里有个分寸：别把 app 绑定也清空了，否则 app('request') 会彻底失效。核心绑定建议只保留 ['app', 'thinkApp', 'thinkEnv']

清洗容器这件事，不是简单的“清空”就完事了，得知道哪些绑着死了也不能丢。

协程内用 $sharedData = [] 而不是 global 的替代方案

其实有一个天然的、安全的上下文载体——协程本地存储（Co::getContext）。它按协程 ID 隔离，天然避免共享冲突。

正确的做法是：

• $ctx = Co::getContext(); $ctx['user_id'] = 123;——这个值只对当前协程可见，不会串到别的请求
• 注意：不要用 Co::set(['hook_flags' => ...]) 之后不恢复，它会影响整个 Worker 进程的 IO 行为，不是协程级别的配置
• Table 是进程级共享存储，适合做缓存，不适合存请求上下文。想存临时数据，优先走 Co::getContext()

真正难的不是知道要清，而是清哪些、什么时候清、清完会不会断链路。比如重置容器后忘了重新 register 自定义 Provider，或者清了 $_SERVER 却没补回 REQUEST_URI，接口就直接 500。这些坑，不跑线上压测根本发现不了。