PHP 8.5.7未改变session_start()函数本身，但默认配置更严格：session.use_strict_mode=1拒绝无效ID、session.cookie_samesite=Lax限制跨站cookie、禁止运行时修改serialize_handler、session_regenerate_id()报错更早更明确。
session_start() 本身没变，但 PHP 8.5.7 启动它时默认加载的配置更严了——不是函数升级，是环境变硬了。
session.use_strict_mode=1 是默认值，不再容忍空或伪造 session ID
PHP 7 默认是 0，PHP 8.5.7 默认为 1。这意味着：
- 客户端传一个不存在的
PHPSESSID（比如清 Cookie 后手动填个旧值），PHP 不再“将就着用”，而是直接拒绝并生成新 ID - 老代码若依赖“未初始化 session 也能写
$_SESSION”（如直接$_SESSION['user'] = 1再调session_start()），会失败或行为异常 - 这是防会话固定（Session Fixation）的关键一环，但上线前必须测试首次访问是否仍能建 session
session.cookie_samesite=Lax 成为默认，跨站请求自动丢 cookie
PHP 7 默认为空字符串（即 SameSite=None 行为），PHP 8.5.7 默认设为 Lax：
- 含表单提交、
<form method="POST">或fetch()跨域 POST 的场景，cookie 不会随请求发出 → 后端收不到PHPSESSID - iframe 嵌入子页面时，若父页和子页域名不同，子页的 session cookie 默认不发送
- 若业务真需跨站携带（如 SSO 登录回调），必须显式设为
SameSite=None; Secure，且session.cookie_secure=1必须同时开启
ini_set() 动态改 session.serialize_handler 直接报错
PHP 8.5.7 禁止运行时切换序列化处理器：
立即学习“PHP免费学习笔记（深入）”；
-
ini_set('session.serialize_handler', 'php_serialize')在session_start()之后调用 → 触发 Warning：“Cannot modify session.serialize_handler at this time” - 不能在中间件、路由逻辑里临时切 handler（比如想用
php_serialize存对象，再切回php） - 必须在
session_start()前，通过php.ini或脚本开头的ini_set()固定好，否则后续所有 session 操作都可能失败
session_regenerate_id() 报错更早、更明确
不再是静默失败，而是提前中断非法调用：
- 在
session_start()之前调用 → Fatal error：“Cannot regenerate session id when session is not active” - 传
false作第二个参数，但当前 session 已销毁或存储 handler 的destroy()返回非bool（如null）→ 直接抛ValueError，而非 PHP 7 的返回false - 这意味着：任何封装了
session_regenerate_id()的登录/权限切换逻辑，必须确保 session 已启动、且 handler 实现严格返回true/false
真正容易被忽略的是：这些默认值只影响新启动的 session；已存在的 session 文件、Redis 中的旧 key 不会自动失效，但下次读取时会按新规则校验——所以问题往往在用户“第二次访问”时才暴露，不是部署完立刻报错。
