租户上下文残留会导致用户看到他人数据、权限校验错乱、数据库连接指向错误租户库；因frankenphp sapi模式进程常驻，$_server、全局变量、静态属性、opcache及已加载类均可能跨请求残留，必须在每次请求入口显式重置租户id、清理静态状态、调用opcache_invalidate()、重连数据库并校验超全局数组。
租户上下文残留会导致什么问题
在 FrankenPHP 的 SAPI 模式（如 frankenphp-worker）下，PHP 进程常驻内存，$_SERVER、全局变量、已加载的类、甚至 opcache 中的脚本状态都可能跨请求残留。如果租户标识（比如通过子域名、请求头或路由参数注入）被缓存到全局作用域（如 $tenant 变量、静态属性、单例容器），后续请求就可能误用前一个租户的数据——典型表现是用户看到别人的数据、权限校验错乱、数据库连接指向错误租户库。
必须在每次请求开始时重置租户上下文
FrankenPHP 不提供类似 Laravel 的「请求生命周期钩子」自动清理机制，所有上下文隔离需手动控制。关键是在 frankenphp.go 或入口 PHP 脚本中，于实际业务逻辑执行前完成重置：
- 不要依赖
register_shutdown_function()或__destruct()清理——它们在请求结束后才触发，无法防止当前请求污染下一个请求 - 必须在
frankenphp.ServeHTTP()调用后、进入框架路由前做初始化，例如在index.php顶部解析租户并覆盖全局状态 - 避免使用
static属性或global变量存储租户 ID；改用请求级容器（如$_SERVER['TENANT_ID']）或传参方式 - 若用了 Doctrine 或 Laravel 的服务容器，确保租户相关服务（如 DB connection factory）是 request-scoped，而非 singleton
用 frankenphp.ClearOpCache() 处理动态加载的租户配置文件
有些多租户方案会按租户名动态 include 配置文件（如 config/tenant-abc.php），而 opcache 默认会缓存这些文件路径。即使租户切换了，旧配置仍可能从 opcache 中读取：
- 在解析出新租户 ID 后、加载其配置前，调用
frankenphp.ClearOpCache() - 仅清除特定文件更安全：用
opcache_invalidate('path/to/tenant-abc.php', true)替代全量清空 - 注意：
frankenphp.ClearOpCache()是 FrankenPHP 特有函数，原生 PHP 不可用；且频繁调用会影响性能，只在租户变更时触发
检查 $_SERVER 和 $_ENV 是否被意外复用
FrankenPHP 会复用 $_SERVER 数组结构，但不会自动重置其中的自定义键。如果你在上个请求里写了 $_SERVER['TENANT_ID'] = 'xyz'，下个请求不显式覆盖，它就还是 'xyz'：
- 每次请求入口处应主动 unset 或重写关键键：
unset($_SERVER['TENANT_ID']);或$_SERVER['TENANT_ID'] = $parsed_tenant_id; - 不要往
$_ENV写运行时值——它在进程启动时就被冻结，修改无效且易混淆 - 可通过
var_dump(array_keys($_SERVER))快速确认是否有残留租户字段
最危险的不是没清理，而是以为自己清理了——比如只清了变量却忘了静态属性，或只清了 PHP 层却没重连数据库。租户上下文清理必须覆盖变量、类状态、OPcache、超全局数组、外部连接这五个层面，缺一不可。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
