Facade在Swoole常驻进程中不会自动重置，因其静态代理依赖Container单例和内部静态缓存，导致Log、Cache、Request等服务状态跨请求污染；必须用app()实例替代Facade进行请求级状态管理。
Facade 在 Swoole 常驻进程中不会自动重置
ThinkPHP 的 Facade 是静态代理，底层通过 Container::getInstance()->get() 获取实例。在 PHP-FPM 中每次请求都是全新生命周期，Facade 每次调用都走完整解析流程；但在 Swoole 常驻进程里，Container 实例和已绑定的 Facade 映射关系会一直保留在内存中。
这意味着：如果某个 Facade 对应的服务（比如 Log、Cache、Request）在一次请求中被手动修改了状态（如调用了 Log::channel('custom') 切换通道，或 Cache::store('redis') 切换驱动），这个变更会持续影响后续所有请求——除非你显式重置。
- 不要在控制器/中间件里对 Facade 实例做「全局性」配置变更（如
Db::connect($config)、Log::use(...)） - 若必须切换，优先使用非静态方式：
app('log')->channel('custom')，并确保该实例不被长期持有 -
RequestFacade 尤其危险：它的底层think\Request实例一旦被赋值，Request::instance()会直接返回缓存对象，导致后续请求拿到上一个请求的$request->param()、$request->url()等数据
Facade 绑定的服务实例可能跨请求污染
ThinkPHP 默认将很多服务（如 db、cache、queue）注册为「单例」（singleton）。Swoole 启动后，这些单例在 WorkerStart 阶段就被初始化并常驻内存。问题在于：某些服务内部持有连接、上下文或缓冲区，而它们并不知道要“按请求隔离”。
典型例子是 Db Facade：如果你用的是 MySQL 连接池（'type' => 'swoole'），那没问题；但若仍用默认 mysql 驱动，Db::table('user')->find(1) 实际复用的是同一个 PDO 实例——而 PDO 不是线程/协程安全的，高并发下可能读到错乱结果或触发 MySQL server has gone away 错误。
立即学习“PHP免费学习笔记（深入）”；
- 确认数据库配置中
'type'已设为swoole，并启用连接池（'pool_size'> 1） - 避免在业务逻辑中直接操作
Db::getConnection()返回的原始 PDO 对象 - 缓存类（
CacheFacade）若底层用的是File驱动，文件锁和路径拼接可能因请求上下文残留出错；生产环境务必切到redis或memcached
Facade 的静态缓存与 Swoole 生命周期冲突
部分 Facade（如 Config、Lang）内部做了静态属性缓存，用于加速重复读取。例如 Config::get('app.debug') 第一次调用会从配置文件加载，之后直接返回静态数组。这在 FPM 下无害，但在 Swoole 中，如果你在运行时动态修改了配置（比如通过 HTTP 接口热更新 config/app.php），Config Facade 不会感知变化，依然返回旧值。
更隐蔽的问题是 Lang：它缓存了当前语言包内容，如果多个请求分别设置了不同 lang 参数（如 ?lang=zh-cn 和 ?lang=en-us），Lang::get('hello') 可能始终返回第一个请求的语言内容。
- 禁用运行时配置热更新，或改用
app('config')实例并手动清空其内部缓存（app('config')->reset()） - 多语言场景下，不要依赖
LangFacade，改用app('lang')->setLocale($locale)->get('key')并确保每次请求都新建 locale 上下文 - 所有涉及「请求级状态」的 Facade，都要检查其源码中是否有
private static $xxx属性——有就大概率是坑
调试时 Facade 行为和 CLI 环境不一致
你在命令行执行 php think swoole 启动服务后，用 var_dump(Log::getChannel()) 看到的是 Worker 初始化时的状态；但你在浏览器发 HTTP 请求后，再用 Log::info('test') 写日志，实际走的可能是另一个通道（比如被中间件切换过）。这种不一致会让调试变得极其迷惑。
根本原因是：Facade 的静态代理行为本身没变，但背后容器里绑定的实例可能已被中间件、钩子或业务代码替换。而 CLI 启动时没有走完整 HTTP 生命周期，很多中间件根本没执行。
- 调试时优先用
app('log')替代LogFacade，可明确看到当前请求绑定的实际实例 - 在
onRequest回调开头加app('log')->info('request start', ['uri' => $request->url()])，验证日志是否真的写入预期通道 - 不要在
WorkerStart中调用任何 Facade 方法来“预热”，它可能污染后续请求的初始状态
app() 容器获取实例并显式管理生命周期。 
