FrankenPHP在worker模式下PHP常驻内存，需重置全局变量、静态属性等请求级状态，否则引发数据错乱；应使用frankenphp_request_init钩子清理，并改用request()替代$_SERVER等冻结变量。
FrankenPHP 在 worker 模式下启用常驻内存机制，PHP 进程不会随每次请求销毁，因此 全局变量、静态属性、单例实例、未清理的缓存等都会跨请求复用。这在 Laravel 等框架中极易引发数据错乱：比如上一个用户的 session ID 被下一个用户读到、配置被意外覆盖、数据库连接复用导致事务残留、日志上下文污染等。
明确哪些状态必须重置
不是所有全局状态都危险，关键是识别“请求级”而非“应用级”的数据：
-
$_SERVER、$_GET、$_POST、$_COOKIE、$_FILES —— 完全不可信，已被 FrankenPHP 冻结为首次请求快照，必须改用
request()辅助函数获取实时值 - 全局数组（如 $GLOBALS['user']、$config） —— 若在中间件或控制器中动态赋值，下次请求会沿用旧值；应改为 request()->attributes 存储，或使用服务容器绑定 request-scoped 实例
- 静态属性（如 User::$current、Cache::instance()） —— 必须在每次请求开始时显式重置或重新初始化
-
Laravel 的 app() 全局辅助函数本身安全，但若你手动 bind 了 request-aware 的绑定（如
$app->bind('current_user', function () { return Auth::user(); })），该绑定会被复用，需改用app()->scoped()或 request()->user()
利用 FrankenPHP 请求生命周期钩子
FrankenPHP 提供 frankenphp_request_init 和 frankenphp_request_shutdown 两个 PHP 扩展钩子，可在每次请求真正开始前和结束后执行清理逻辑：
- 在
bootstrap/app.php或自定义服务提供者中监听frankenphp_request_init事件，重置关键静态状态：if (function_exists('frankenphp_register_hook')) {<br> frankenphp_register_hook('frankenphp_request_init', function () {<br> User::$current = null;<br> Cache::flushRequestCache();<br> });<br>} - 避免在
register()或boot()中做任何依赖请求上下文的操作（如读取 Host、检查 token）
框架适配：Laravel 用户重点操作
Laravel 本身已对 Octane 做了大量兼容改造，但部分手动扩展仍需自查：
立即学习“PHP免费学习笔记（深入）”；
- 禁用所有基于
$_SERVER的判断：如if ($_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https')→ 改为request()->secure() - 移除在
AppServiceProvider@register()中注册的单例（singleton），改用app()->scoped()绑定请求生命周期实例 - 检查第三方包是否支持 Octane：运行
php artisan octane:check可扫描常见不兼容模式（如静态缓存未清、全局变量写入） - Session、Auth、View 等核心组件默认已适配，但自定义 Session 驱动或 Auth Guard 若用了静态变量，必须重写为 request-aware
验证与调试技巧
错乱问题往往偶发，需主动暴露：
- 在中间件中添加临时检测：
if (app()->has('current_user') && app('current_user')->id !== request()->user()?->id) { Log::warning('User context mismatch'); } - 启用 FrankenPHP 的 metrics（
servers { metrics }），观察frankenphp_worker_requests_total和frankenphp_worker_memory_bytes是否异常增长，内存泄漏常伴随状态错乱 - 用
php artisan octane:reload触发热重载后立即测试，确认是否复现 —— 若只在 reload 后出问题，大概率是静态状态未重置
