session_destroy()在FrankenPHP worker模式下不生效，因其依赖传统CGI的请求级初始化/销毁周期，而worker常驻进程使PHP内置session扩展处于“半挂起”状态，锁未释放、状态残留，导致登出后仍可恢复旧会话。
FrankenPHP worker 模式下不能用 session_start() + session_destroy() 这套传统流程，否则会失效、残留甚至报错。必须完全绕过 PHP 原生 session 扩展，手动接管生命周期。
为什么 session_destroy() 在 worker 下不生效
worker 是常驻进程 + 多协程模型，session_start() 依赖每次请求初始化/销毁的 CGI 生命周期，而 FrankenPHP 不触发这个流程。调用 session_destroy() 后，$_SESSION 可能看起来清空了，但下次请求仍会从旧 session 文件（或 Redis 中）自动恢复 —— 因为底层 session 状态没被真正切断，锁也可能未释放。
- 现象：登出后刷新页面，
$_SESSION又回来了 - 根本原因：PHP 内置 session 扩展在 worker 下处于“半挂起”状态，
session_write_close()不可靠，session_regenerate_id(true)会静默失败 - 验证方式：在登出脚本末尾加
var_dump(session_status() === PHP_SESSION_NONE);，常返回false，说明 session 实际仍 active
正确关闭 Session 的三步手动操作
你得自己读写存储、清除 Cookie、并确保 ID 不再复用。以 Redis 为例（FrankenPHP 官方推荐）：
- 从
$_COOKIE[session_name()]或getallheaders()['Cookie']提取PHPSESSID值（注意：不能依赖session_id()，它可能返回空或旧值） - 用 Redis 删除对应 key：
$redis->del("sess_{$sid}");（key 格式需与写入时一致，通常是"sess_" . $sid） - 用
setcookie()清除客户端 Cookie：setcookie(session_name(), '', time() - 3600, '/', '.yourdomain.com', true, true);，参数必须和登录时完全一致（尤其是 domain/path/secure/httponly） - 可选但推荐：调用
session_regenerate_id(true)前先ini_set('session.use_strict_mode', 0)，避免 strict mode 在 ID 校验阶段直接拦截
容易漏掉的关键点
很多团队卡在“登出后还能进后台”，问题往往不在逻辑，而在细节：
立即学习“PHP免费学习笔记（深入）”；
-
setcookie()必须在任何输出之前调用，包括空格、BOM、echo ""；worker 模式下响应头更敏感，一个 warning 都可能导致 header 发送失败 - 若用了 Nginx 反向代理，确认有
proxy_set_header Cookie $http_cookie;，否则前端传来的PHPSESSID根本到不了 PHP 层 - 不要在登出后立即重定向就以为完事 —— 浏览器可能缓存了旧 Cookie，建议重定向目标页（如 login.php）开头也执行一次 Cookie 清理逻辑
- Redis 中的 session 数据是序列化字符串，用
unserialize()解析时，若框架（如 ThinkPHP 5.1）用了自定义序列化器，必须匹配，否则删错 key
真正难点不在“怎么删”，而在于“删干净”——要同时清理服务端存储、客户端凭证、以及 FrankenPHP 进程内可能残留的 session 上下文引用。一旦漏掉任意一环，用户就可能跳过登录直接回滚到上一个会话。
