worker模式下session_start()仍可用，但行为本质不同：因进程常驻，它复用存储驱动和连接，每个请求仍独立反序列化$_session，需显式调用、禁用auto_start，并确保cookie参数（path/domain/secure）匹配且无提前输出。
Worker 模式下 session_start() 还管用吗
管用，但行为和 PHP-FPM 下有本质区别。FrankenPHP 的 worker 进程常驻内存，session_start() 不再每次“新建会话环境”，而是复用已初始化的 session 处理器、存储驱动（如 files、redis）和底层连接。这意味着：同一 worker 进程内多个请求共享 session 存储实例，但每个请求仍拥有独立的 $_SESSION 数据副本——这是由 PHP 内部在请求开始时自动反序列化、请求结束时自动序列化保证的。
常见错误现象：session_start(): Session cannot be started after headers have been sent 依然会出现，但更隐蔽：比如某个中间件提前输出了空格或 BOM，导致后续所有请求（不止当前）在该 worker 生命周期内都无法开启 session；又或者你误在全局作用域调用 session_start()，它会在 worker 启动时就执行，破坏请求隔离。
- 务必在每个需要 session 的请求入口（如控制器方法）中显式调用
session_start()，不要依赖session.auto_start=1 - 确认
session.save_handler配置为线程安全的后端（如redis或memcached），避免files在高并发下出现锁争用或文件损坏 - 如果使用自定义 session 处理器，确保其实现了
validateId()并启用session.use_strict_mode=1，防止会话固定攻击
登录态数据存在哪？怎么避免跨用户污染
登录态数据仍存于 $_SESSION，但关键点在于：worker 进程不销毁，而 $_SESSION 是每个请求独占的——PHP 在请求开始时从存储中读取并反序列化对应 session_id 的数据到当前请求的 $_SESSION 数组，请求结束时再序列化写回。所以只要 session_id 正确隔离，就不会跨用户污染。
容易踩的坑是「手动复用变量」：比如你在中间件里把 $_SESSION 赋值给一个全局静态属性或类属性，后续请求可能读到上一个用户的残留数据。
- 绝对不要把
$_SESSION直接赋给static $user或self::$sessionData - 避免在服务容器中注册 session 相关的单例（如
SessionManager），除非它明确按请求生命周期重建 - 检查框架是否在 worker 模式下正确重置了 request/response 对象——CodeIgniter 4 和 Laravel 11 已适配，但老版本或自研框架需确认
$_SESSION是否被意外缓存
“记住我”功能还能用 setcookie() 吗
能，而且必须用。FrankenPHP 的 worker 模式只改变 PHP 进程生命周期，并不干涉 HTTP 响应头机制。setcookie() 仍然向浏览器发送 Set-Cookie 头，和 PHP-FPM 完全一致。
但要注意：worker 进程常驻，意味着 setcookie() 调用后，该 cookie 会随响应一起发出，但后续请求中 cookie 的校验逻辑（比如解密 token、查数据库）仍需你自己实现——FrankenPHP 不提供自动 remember-me 支持。
-
setcookie()的$expires参数必须设为未来时间戳（如time() + 30 * 86400），不能传0（会变成会话 Cookie） - “记住我”的 token 应该是随机生成、带签名、绑定用户 agent/IP 的长字符串，存入数据库，而非直接把 user_id 加密后塞进 cookie
- 不要在
setcookie()后再修改$_SESSION，否则可能因输出缓冲未刷新导致 header 已发送错误
为什么登录后跳转 dashboard.php 会丢失 session
最常见原因是 session cookie 的 path 或 domain 设置不匹配。比如你在 login.php 中调用 setcookie('PHPSESSID', ..., time(), '/admin')，但 dashboard.php 在根路径 / 下，浏览器就不会携带这个 cookie。
另一个隐蔽原因是 FrankenPHP 默认启用 session.cookie_httponly=1 和 session.cookie_secure=1（仅 HTTPS），如果你本地开发用 HTTP 访问，session.cookie_secure 为 true 会导致浏览器拒绝发送 cookie。
- 检查
session.cookie_path是否为'/'（推荐），避免路径限制 - 开发环境临时设
session.cookie_secure=0，生产环境必须为1并确保 Caddy 启用了 TLS - 用浏览器开发者工具的 Application → Cookies 面板，确认 PHPSESSID 是否存在、Domain/Path 是否匹配、Expires 是否合理
真正麻烦的是 session ID 的传递链：从登录表单提交 → 服务端验证 → session_start() + 写 $_SESSION → header('Location: ...') → 浏览器发起新请求并带上 cookie。任何一环出错，都会让下个请求看到空的 $_SESSION。worker 模式没增加新问题，只是让这些问题更难复现——因为不是每次请求都重启进程，状态更容易“卡住”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
