session.use_strict_mode = 1不能单独防住会话固定，仅拒绝未初始化的会话id；必须配合登录后立即调用session_regenerate_id(true)并确保无任何输出，才能完整防御。
session.use_strict_mode = 1 能防住会话固定吗
不能单独防住，但它是必要防线。它只拒绝「未初始化的会话 ID」——比如攻击者提前发一个 PHPSESSID=abc123 链接，用户点击后 PHP 发现这个 ID 对应的 session 文件根本不存在，就会丢弃它、生成新 ID。但它**不拒绝已存在的合法 ID**，哪怕这个 ID 是攻击者诱导用户携带的（比如通过登录页 URL 传参）。所以它防的是“伪造空会话”，不是“劫持已有会话”。
为什么必须配合 session_regenerate_id(true) 才算完整防御
登录成功那一刻，是会话固定攻击最危险的时间点。此时攻击者手里攥着的，很可能就是用户刚用的那个合法但受控的会话 ID。你得立刻把它换掉。
-
session_regenerate_id(true)会销毁旧会话文件，强制生成全新 ID，并把当前$_SESSION数据迁移到新会话中 - 必须在写入关键登录态（如
$_SESSION['user_id']）之后、任何输出（包括 header、echo、空格）之前调用，否则可能失败或被绕过 - 如果只调用
session_regenerate_id()不带true，旧会话文件仍保留，攻击者还能读取其中刚写入的敏感数据
php.ini 中 session.use_strict_mode 的实操配置
在 php.ini 中设置这一项只是第一步，还得确认底层存储支持。文件存储默认支持，但如果你用了自定义 SessionHandlerInterface 实现（比如 Redis），就得自己在 read() 方法里做判断：若传入 ID 对应的数据不存在，就返回空字符串（PHP 会据此触发新会话创建）。
- 编辑
php.ini，确保有：session.use_strict_mode = 1 - 同时建议关闭不安全选项：
session.use_trans_sid = 0（禁用 URL 传参泄露 ID）、session.cookie_httponly = 1、session.cookie_secure = 1（后者仅限 HTTPS 环境） - 修改后必须重启 Web 服务器（如
sudo systemctl restart apache2或sudo nginx -s reload），仅 reload PHP-FPM 不生效 - 验证是否生效：访问一个未初始化 session 的页面，用 curl 模拟带非法 ID 请求：
curl -b "PHPSESSID=fake123" http://yoursite.com/，响应中 Set-Cookie 的 ID 应该和 fake123 不同
ThinkPHP 等框架里容易漏掉的关键点
ThinkPHP 默认不会在登录成功后自动调用 session_regenerate_id(true)，它把 session 生命周期完全交给 PHP 原生逻辑。这意味着你得在登录逻辑的最后、重定向前手动加这一行——而且得确保没其他代码提前输出内容。
- 常见错误：在登录控制器里先
dump($_SESSION)或写了echo 'ok'，再调用session_regenerate_id(true)→ 触发headers already sent错误，重置失败 - 更隐蔽的问题：使用了中间件或钩子，在 session_start() 后又写了日志、埋点等输出，同样会破坏重置时机
- 别依赖
session_destroy()替代session_regenerate_id(true)：前者只清数据不换 ID，攻击者仍可用原 ID 访问新会话（如果 session 文件还没被 GC 清理）
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
