很多项目会把 Session 安全配置留到上线前再处理，但 session.use_strict_mode 其实属于应该尽早确认的一项。PHP 8.6 下它的启用方式没有变化：要在 php.ini 里设置并重启环境，本文会顺着“正确开启、作用原理、配套安全项、验证方法”四个问题讲清楚，方便你判断当前配置到底有没有真正生效。
正确开启 session.use_strict_mode 的方法
在 PHP 8.6 中，session.use_strict_mode = 1 的推荐做法仍然是直接写入 php.ini。这一点和之前版本一致，重点是不要把它当成一个适合运行时临时切换的选项。
先找到当前正在使用的配置文件路径，可以通过 php --ini 或 phpinfo() 确认。随后在对应的 php.ini 中找到或添加下面这一行：
session.use_strict_mode = 1
需要注意两点：
- 这一行不能处于注释状态，也就是前面不能带分号
;。 - 修改完成后要重启 Web 服务器或 PHP 运行环境，例如 Apache、Nginx + PHP-FPM，CLI 场景也要确保重新加载配置。
如果你只是写了类似下面的代码：
ini_set('session.use_strict_mode', '1');
那在 PHP 8.6 中依然不能视为可靠启用。尤其在 CGI/FastCGI 模式下，这类修改可能会被忽略，因此不适合拿来当正式配置方案。
为什么这个选项必须开
session.use_strict_mode 的核心作用，是拒绝未初始化或伪造的会话 ID，避免应用直接接收外部塞进来的 Session 标识。
如果不开启严格模式，攻击者可能提前构造一个会话 ID，比如通过 URL 参数传入 ?PHPSESSID=abc123，再诱导用户使用这个 ID 访问站点。这样一来，应用就有机会沿用这个攻击者预先指定的会话，从而形成典型的 Session Fixation，也就是会话固定攻击。
开启后，PHP 的处理逻辑会更严格：
- 只接受由 PHP 自己生成、并且已经写入存储系统的 session ID。
- 对外部传入的非法 ID、旧 ID 或未初始化 ID 进行拒绝。
- 在发现 ID 不合法时，自动分配一个新的会话 ID，而不是继续沿用可疑值。
这也是为什么它经常被归为 PHP Session 安全的基础配置项之一。单看配置只是一行，但它直接影响应用是否会无条件信任用户提交的会话标识。
建议同时检查的会话安全配置
仅开启 session.use_strict_mode 还不够，实际部署时最好把同一组常见安全项一起确认。它们通常也都放在 php.ini 中：
session.use_cookies = 1 session.use_only_cookies = 1 session.cookie_httponly = 1 session.cookie_secure = 1; 上线环境必须开（开发若无 HTTPS，可临时设为 0） session.cookie_samesite = Lax session.use_trans_sid = 0
这组配置分别对应几个常见目标：
session.use_cookies = 1：启用 Cookie 传递 Session。session.use_only_cookies = 1：只允许通过 Cookie 传递，减少通过 URL 暴露 Session ID 的风险。session.cookie_httponly = 1：避免前端脚本直接读取 Session Cookie。session.cookie_secure = 1：要求只在 HTTPS 下发送 Cookie，生产环境应开启。session.cookie_samesite = Lax：降低跨站请求携带 Cookie 的风险。session.use_trans_sid = 0：关闭透明 SID，避免 Session ID 被拼接到 URL。
如果把这些项和严格模式一起看，会更容易理解它们的分工：严格模式负责拒绝非法会话 ID，其余设置则负责尽量别把 Session ID 暴露到不该出现的地方。
怎么验证配置是否真的生效
改完配置并重启之后，最好做一次实际验证，而不是只看文件里是否写了 1。
可以先在测试脚本中加入下面这段代码：
<?php
var_dump(ini_get('session.use_strict_mode')); // 应输出 string(1) "1"
session_start();
// 再用非法 ID 访问（如手动改 URL 加 ?PHPSESSID=test123），应看到新会话 ID 被分配，旧 ID 不延续
echo session_id();
?>
验证时主要看两个结果：
ini_get('session.use_strict_mode')是否返回"1"。- 当你手动构造一个非法会话 ID，比如访问时附带
?PHPSESSID=test123，应用是否会拒绝复用它，并重新分配新的session_id()。
只有这两个条件都满足，才说明严格模式已经按预期生效。否则就需要回头检查：你改的是不是当前实际加载的 php.ini，以及运行环境是否真的完成了重启或配置重载。
一个容易忽略但值得默认开启的开关
session.use_strict_mode 的配置不复杂，真正容易出问题的是“以为开了，其实没生效”。在 PHP 8.6 里，稳妥做法仍然是修改 php.ini、重启服务，再通过 ini_get() 和非法 ID 测试双重确认。对线上 PHP 应用来说，这一项很适合列入默认安全基线。
