frankenphp worker模式下单例对象跨请求长期存活，不会自动销毁或重置；必须显式清空static状态、释放pdo/缓存/文件资源，并避免将请求级数据存入单例。
FrankenPHP worker 模式下单例对象不会自动销毁
单例对象在 FrankenPHP 的 worker 模式下是跨请求长期存活的，self::$instance 不会在每次请求结束时重置或析构。这不是 bug，而是常驻进程模型的必然行为——PHP 解释器不重启，静态变量和单例实例就一直留在内存里。如果你在单例中存了 $userId、$requestId 或临时查询结果，下一个请求会直接读到上一个请求的残留数据，造成严重污染。
必须显式重置单例状态，不能依赖“请求结束自动清空”
传统 PHP-FPM 下单例看似“安全”，是因为每个请求跑在独立进程中；而 FrankenPHP 的 worker 是同一个进程反复处理请求，所有静态属性都持续存在。因此：
- 所有带状态的单例（如含
private static $currentUser）必须在每次请求入口或kernel.terminate阶段手动重置，例如self::$currentUser = null; - 避免在
__construct()中加载请求级数据（如从$_SERVER或 JWT 解析用户），应改为懒加载 + 显式初始化方法（如initForRequest()） - 检查单例是否持有 PDO 实例、缓存句柄、文件资源等——这些必须调用
$pdo = null;、cache()->clear()、fclose()等释放底层资源，仅unset()不够 - 若单例内部使用了
static $cache = [];，需在请求末尾清空：self::$cache = [];，而非指望 GC 自动回收
不要把单例当“请求上下文容器”来用
常见错误是把本该属于请求生命周期的数据（如认证信息、路由参数、临时配置）塞进单例静态属性。这类数据应当通过以下方式传递：
- 函数参数或方法入参（最干净）
-
php\Context（FrankenPHP 原生支持，比$_GLOBALS更可控） - 依赖注入容器（如 Symfony DI）中声明为
scope: "request"的服务 - 闭包绑定（
fn() => $data）配合中间件注入，避免静态持有
一旦发现某个单例类的 getInstance() 返回的对象在不同请求中输出不同 var_dump($obj->userId)，说明它已被污染，立刻排查其构造逻辑和状态写入点。
验证单例是否真被清理干净
光靠“写了 self::$xxx = null”不等于清理成功。实际检查手段包括：
- 在请求末尾加
var_dump(array_keys(get_class_vars('YourSingleton')));，确认所有预期状态字段已重置为初始值（而非仍为字符串/对象） - 用
gc_collect_cycles()后检查内存占用是否回落（尤其批量请求后） - 对持有资源的单例，执行
lsof -p $(pgrep -f 'frankenphp')查看文件描述符是否随请求增长——若持续上升，说明资源未释放 - 在单例的
__destruct()方法里打日志（注意：worker 模式下它几乎不会被调用，仅用于验证是否误触发）
真正难处理的不是“怎么清”，而是“哪些地方悄悄持有了引用”。比如一个单例 A 在构造时注册了事件监听器 Event::on('user.login', function () use ($this) { ... })，这个闭包强引用了 $this，即使你重置了 A::$instance，对象也不会被回收。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
