根本原因是frankenphp基于协程复用进程，未显式配置时会因session.use_strict_mode=1拒绝非法id、并发共享session文件、或前端未正确携带cookie导致验证码值读取失败；推荐改用redis缓存+token方案替代session存储。
FrankenPHP 下 Symfony 验证码依赖的 Session 行为不稳定，根本原因不是验证码逻辑本身，而是 FrankenPHP 的会话生命周期管理与传统 PHP-FPM 存在差异：它默认启用 session.use_strict_mode=1 且不自动处理 Session ID 复用冲突，导致验证码生成时写入的 $_SESSION['captcha_code'] 在验证请求中读不到或被清空。
为什么 FrankenPHP 的 Session 会“丢失”验证码值
FrankenPHP 是基于 Swoole 的协程 PHP 运行时，Session 不再由 Apache/Nginx + PHP-FPM 按请求隔离式启动，而是复用 worker 进程和内存上下文。若未显式配置，会出现以下情况：
- 多个并发请求可能共享同一 session 文件（尤其当
session.save_handler=files且未加锁） -
session_start()在无 Cookie 的首次请求中会生成新 ID，但后续 AJAX 验证请求若未携带该 ID（如跨域、fetch 未设credentials: 'include'），就会开启另一个 session，读不到之前存的$_SESSION['captcha_code'] - 默认启用 strict mode 后，若客户端传入一个不存在的 session ID（比如旧 Cookie 或伪造值），FrankenPHP 直接拒绝初始化 session，
$_SESSION为空数组
修复 Session 初始化与传递链路
确保验证码生成与验证两个端点使用完全一致的 Session 上下文：
- 在验证码生成控制器（如
CaptchaController::show()）开头强制调用session_start(['use_strict_mode' => 0])，绕过 strict mode 对首次 ID 的拦截（仅用于验证码场景，不影响其他安全逻辑） - 前端请求验证码图片时，必须带凭证：
<img src="/captcha" crossorigin="anonymous" referrerpolicy="no-referrer">改为<img src="/captcha" referrerpolicy="no-referrer">并确保 Nginx / Caddy 反向代理未剥离Cookie请求头 - 验证表单提交时，AJAX 请求需显式携带凭证：
fetch('/login', { credentials: 'include' })；若用表单 submit，则确保 action 页面与当前页同源，浏览器自动附带 Cookie - 检查
php.ini中session.cookie_samesite是否设为Lax或Strict——FrankenPHP 对SameSite=Strict更敏感，建议临时设为Lax测试
改用非 Session 的验证码存储方案（推荐）
Session 在 FrankenPHP 下本质是“共享内存+文件锁”的妥协方案，稳定性不如无状态设计。更可靠的做法是把验证码值存在服务端缓存并绑定唯一 token：
- 生成验证码时，用
random_bytes(16)生成 token，存入cache.app（Redis 或 APCu），键为captcha_<token></token>，TTL 设为 300 秒 - 返回该 token 给前端（例如嵌入 hidden input 或 HTTP header），同时图片 URL 带参数：
/captcha?token=abc123 - 验证时不再读
$_SESSION，而是查$cache->get('captcha_'.$request->query->get('token')) - Symfony 示例中可封装为
CaptchaService，避免直接操作底层缓存 API
这个方案彻底规避了 FrankenPHP 的 Session 生命周期问题，也更适合水平扩展部署。真正容易被忽略的是：很多开发者在迁移至 FrankenPHP 后仍沿用传统 PHP-FPM 的 Session 用法，却没意识到 session ID 的分发、校验、销毁逻辑已被协程模型重写——不是“不能用”，而是“要用对方式”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
