frankenphp worker模式下，单例对象常驻内存会导致跨请求数据污染，因static实例生命周期远超单次http请求，$server等超全局变量不重置，须用显式传参、request attributes或weakmap隔离请求状态。
会直接导致跨请求数据污染，用户 A 的 request_id、user_id、token 等全被用户 B 读到——不是偶发，是必然。
FrankenPHP Worker 模式下，单例的生命周期远超单个 HTTP 请求
FrankenPHP 启动后，Worker 进程常驻内存，static $instance 一旦初始化就存活整个进程生命周期。而每个 HTTP 请求只是协程或子请求（subrequest）级别的一次调用，__construct() 只执行一次，后续所有请求都复用同一个对象实例。
常见错误写法：
class AuthService
{
private static ?self $instance = null;
public string $token = ''; // ❌ 请求级状态存进单例属性
public int $userId = 0;
private function __construct()
{
// 这里只跑一次！
}
public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}
}
- 请求 1 来了：
$auth = AuthService::getInstance(); $auth->token = 'abc'; $auth->userId = 123; - 请求 2 来了：拿到的还是同一个
$auth，$auth->token仍是'abc'，$auth->userId仍是123—— 即使它根本没登录 - 后果：鉴权绕过、缓存错乱、日志混写、敏感信息泄露
为什么 Coroutine::getContext() 在 FrankenPHP Worker 中不适用
FrankenPHP 的 Worker 模式默认运行在 PHP-FPM 兼容层上，底层不基于 Swoole 协程调度器，Coroutine::getContext() 在非 Swoole/Co 环境中不可用或始终返回空数组。
你不能依赖它做请求隔离。试图调用会触发警告或静默失败，且无法 fallback。
-
Coroutine::getContext()是 Swoole 扩展提供的 API，FrankenPHP 默认不加载该扩展 - 即使手动启用，FrankenPHP 的 HTTP worker 并不使用 Swoole 的协程上下文管理机制
- 检查方式：
extension_loaded('swoole')返回false；function_exists('Swoole\Coroutine::getContext')为false
安全存请求状态的三种可行方式
必须把“属于当前请求”的数据，绑定到请求本身，而不是类实例或静态变量。
-
显式传参：把
$request或提取后的$userId、$token作为参数传入业务方法，而非塞进单例属性 -
Request 对象绑定：利用 FrankenPHP 提供的
Request实例（来自Symfony\Component\HttpFoundation\Request），用$request->attributes->set('user', $user)存，$request->attributes->get('user')取 —— 属性作用域严格限定在本次请求 -
WeakMap 缓存连接级状态（仅限 WebSocket / long-polling 场景）：若 Worker 处理的是长连接，可用
WeakMap关联连接资源与状态，键必须是$connection对象，不能是 ID 字符串；PHP ≥ 8.0 可用，且连接销毁后自动清理
最易被忽略的一点：框架自动注入的“单例服务”（如 Laravel 的 AuthManager、Symfony 的 TokenStorage）内部如果偷偷调用了 Request::createFromGlobals() 或读取 $_SERVER['HTTP_AUTHORIZATION']，在 FrankenPHP Worker 中会读到上一个请求残留的超全局变量值——因为 $_SERVER 不会在每次请求间重置。务必检查这些组件是否做了请求上下文隔离，否则连框架自带的 Auth 都不可信。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
