PHP session.use_strict_mode 开启后旧登录流程为什么失败

把 session.use_strict_mode 从关闭改成开启后，旧登录流程常见的表现是：浏览器明明带着 PHPSESSID，登录页却读不到原先写入的 $_SESSION，或者每次请求都像新会话。根因通常不是 Cookie 没发出，而是旧代码先手工指定了一个 Session ID，存储端并没有确认它是已初始化的有效 ID。

先看现象：Cookie 在，但会话数据像丢了

这类问题最好先记录三项值：请求到达时的 session_id()、session_status()，以及存储端是否存在对应的 Session 数据。若请求头带有 PHPSESSID=legacy-id，但服务端没有名为它的会话记录，开启严格模式后 PHP 不会把它当成可以继续使用的会话。浏览器随后会收到一个新的 ID，旧流程期待的购物车、验证码或登录前跳转地址自然就不见了。

一个容易误判的点是：Cookie 的存在只说明客户端提交了字符串，不说明这个字符串已经对应到服务器上的 Session。先把“有 Cookie”和“有有效会话”分开判断，排查会快很多。

严格模式拒绝的是什么

PHP 官方文档把 session.use_strict_mode 定义为严格 Session ID 模式：开启后，模块不接受未初始化的 Session ID；浏览器提交这类 ID 时，会给浏览器发送新的 ID。它的目的正是避免攻击者诱导应用采用一个攻击者提前知道的会话标识，因此官方建议通用站点开启它。

旧系统最常见的冲突写法是先调用 session_id($id)，再执行 session_start()，并假设存储端会自动接受这个 ID。严格模式下，这个假设不成立。下面的代码不是“Cookie 失效”，而是请求带来的 ID 没有通过服务端的有效性判断：

把预设 ID 改成创建会话后登录

修复思路不是关闭严格模式，而是取消对外部 Session ID 的信任。登录页先让 PHP 按 Cookie 或默认策略启动会话，把登录前需要保留的数据写入 $_SESSION；账号密码确认成功后，再轮换 Session ID 并写入用户身份。这样既保留了登录前上下文，也不会把一个攻击者可预知的 ID 带进登录态。

如果登录流程跨多个入口，重点是保证它们使用同一套 session.save_path、session.name 和 Cookie 范围。若使用 session_set_save_handler()，还要确认自定义 handler 提供 validateId() 或对应的 validate_sid 回调；官方文档明确指出缺少它时，严格模式实际上会被禁用。

上线前检查这四个点

可以在测试环境临时记录 ID 的哈希而不是原值，并分别测试“无 Cookie”“Cookie 对应已存在 Session”“Cookie 是随机未初始化 ID”三种请求。最后一种请求应得到新的有效 ID；如果自定义存储仍接受随机 ID，优先检查 handler 的校验回调，而不是马上把配置改回关闭。

常见问题

开启严格模式后，所有用户都会被退出吗？

不会。已有且能被当前 Session 存储验证的 ID 可以继续使用；受影响的是未初始化、已过期或无法在当前节点找到的 ID。

能不能为了兼容旧登录流程关闭 strict_mode？

不建议。应移除外部指定 ID 的流程，并让登录成功时轮换 ID。短期灰度时也要先确认自定义 handler 与多节点存储一致。

session_regenerate_id(true) 会不会删除登录信息？

正常情况下它轮换标识并清理旧会话文件，当前会话数据仍由新的 ID 继续承载；调用后再写入用户身份最容易避免竞态和误读。

SameSite 能解决 strict_mode 导致的登录失败吗？

不能。SameSite 控制跨站请求是否携带 Cookie，strict_mode 判断 Session ID 是否已由服务端初始化，二者解决的是不同层面的问题。