ThinkPHP Facade缓存实例在长进程里会不会串数据-ThinkPHP-PHP中文网

facade调用本身不缓存实例，但容器对单例绑定的实例会复用；在swoole等常驻进程环境下，若request、db、log等请求级服务被误设为单例或未重置，易导致跨请求状态串扰。

thinkphp facade缓存实例在长进程里会不会串数据

Facade 调用本身不缓存实例，但容器实例会被复用

Facade（如 Db::table()、Cache::get()）不是静态类，而是通过 __callStatic 动态代理到容器中解析出的实例。关键点在于：容器（think\Container）默认对单例绑定（bind($abstract, $concrete, true)）会复用已解析的实例——而 Swoole/Workerman 这类常驻进程环境下，这个“已解析实例”不会随请求结束自动销毁。

所以问题不在 Facade，而在容器是否把服务注册成了单例，以及该实例是否持有请求级状态（比如 Request、Response、数据库连接里的 lastSql、事务状态等）。

哪些 Facade 实例容易串数据？

以下 Facade 对应的底层实例，若未重置或隔离，极易在长进程里跨请求污染：

Academic Reader

PDF转Markdown转换器——从PDF文件提取文本、表格和公式，生成干净的Markdown。适用于PDF文档转换、内容提取、解析等场景。

下载

Request 和 Response：TP 默认把它们塞进 static::$instance 或 $_SERVER，Swoole 复用进程时这些全局位置不会自动清空，下次请求读到的是上一次残留的 input()、header()、cookie()
Db（Connection 实例）：PDO 连接对象本身可复用，但事务未提交/回滚、lastInsertId、getLastSql() 等状态会残留；若用了 Db::startTrans() 但没配 finally，后续请求可能意外进入事务上下文
Log：如果日志处理器（如 FileHandler）被复用且未按请求重设文件名或上下文，多请求日志会混写到同一行或覆盖
自定义 Facade 绑定的类：若构造时缓存了 $this->userId = input('user_id') 这类请求参数，又没在每次调用前重置，就会串

怎么避免 Facade 实例串数据？

核心原则是：**让请求级服务不进单例池，或进池后强制重置**。具体操作包括：

不要把 Request、Response、Session 这类强请求依赖的服务注册为单例；TP 默认也不是单例，但如果你手动 Container::singleton('request', ...) 就踩坑了
在 Swoole 的 onRequest 或中间件入口处，主动重置关键服务：
$container->setInstances([]) 清空所有已解析单例（注意别删 app、env 等核心绑定）；
$container->forget('request'); $container->forget('response'); 再配合 App::getInstance()->bind('request', new Request()) 重建
数据库连接必须启用连接池并配置 'deploy' => 0，避免连接复用导致事务/状态残留；查完记得 Db::close() 或确保事务块有 finally { Db::commit() / rollback() }
自定义 Facade 时，在 getFacadeClass() 返回的服务类里，避免在 __construct 中捕获请求数据；改用方法参数传入，或在每次调用前从 app('request') 拿最新值

为什么 Cache::get() 看似安全却仍有风险？

Cache Facade 本身不带状态，但它的驱动（如 Redis 驱动）实例若被复用，且你用了 Cache::store('redis')->handler() 直接操作底层客户端，就可能因连接未清理、pipeline 未 reset、context 未切换导致命令错乱。更隐蔽的风险是：你缓存的值里包含闭包、__destruct 方法或反序列化后可触发的魔术方法——这些在长进程里反复反序列化，可能引发内存泄漏或逻辑污染。

真正容易被忽略的，是那些你以为“无状态”的服务，其实悄悄绑定了请求上下文；而 Facade 只是那层薄薄的玻璃纸，一捅就破。