FrankenPHP Worker 模式下用户数据默认隔离，但因复用同一执行上下文，若滥用static/global变量、未重置状态或错误缓存资源（如Redis连接），会导致请求间数据串扰；需按CLI脚本规范编写，显式传入请求数据并每次初始化上下文。
不会。FrankenPHP Worker 模式下，两个用户的请求默认不会互相看到彼此的数据——前提是代码没写错、没滥用全局变量或静态属性。
Worker 实例是隔离的，但 PHP 运行时不是沙盒
FrankenPHP 的每个 Worker 脚本（比如 worker.php）会被加载一次，然后反复处理多个请求。但它**不为每个用户创建独立进程或线程**；多个请求会复用同一个 PHP 执行上下文（即同一个 Worker 实例），按顺序串行或并发（取决于 Go 调度）进入该脚本的 handle() 函数。
这意味着：
- 请求之间共享同一份已加载的类定义、函数、
static属性、global变量、未清理的单例实例 - 但每个请求的
$_GET、$_POST、$_SERVER、$_COOKIE是独立注入的，不会自动混用 - 数据库连接、Redis 客户端等资源如果被缓存在静态属性里，且未做连接归属判断，就可能被后续请求误用
常见踩坑点：哪些地方会让用户数据“串”
真正导致“A 用户看到 B 用户数据”的，几乎都来自应用层错误，而非 FrankenPHP 本身设计缺陷。典型场景包括：
立即学习“PHP免费学习笔记（深入）”；
-
static $user = null;之后在handle()中直接赋值但没重置，下一个请求读到的是上一个用户的残留 - 使用
$_SESSION但没调用session_start()或没正确配置 session 存储（FrankenPHP 不自动管理 session 生命周期） - Laravel/Symfony 项目中手动 new 了一个无作用域的 Service，并把它挂到了 static 属性上
- 在 Worker 入口文件里提前 require 了某个“全局状态管理器”，而它内部用了
static缓存用户 ID 或 token - 用了
opcache.enable_cli=1+opcache.file_cache，但没注意缓存文件权限或路径冲突（极少见，但会导致类加载行为异常）
如何验证和规避共享污染
最简单有效的做法是：把 Worker 当作“长生命周期的 CLI 脚本”来写，而不是“带状态的 HTTP 处理器”。关键原则：
- 所有用户相关数据必须显式传入
handle()，不要依赖任何跨请求残留 - 避免在类顶层或函数外使用
static/global存储请求级状态 - 每次
handle()开始时，主动清理或重新初始化关键对象（如 AuthManager、RequestContext） - 用
var_dump(get_defined_vars())在 handle 开头检查是否有意外变量残留（仅调试用） - 启用
frankenphp_metrics监控frankenphp_worker_restarts_total{worker="xxx"}—— 频繁重启往往意味着未捕获的 fatal error 或内存泄漏，背后常藏状态污染
真正难排查的从来不是 FrankenPHP 的模型，而是我们习惯性把“每个请求都从零开始”的思维，套用在了“环境常驻”的上下文中。
