PHP session.lazy_write 为什么让会话数据看似没落盘：保存路径、并发与验证

线上登录接口明明返回成功，下一次请求却像“没有保存会话”。先别急着把锅甩给 session.lazy_write：它的默认含义是“会话内容没变化时不重写文件”，不是“禁止保存会话”。真正需要核对的是保存处理器、session.save_path、文件权限，以及请求何时释放会话锁。

先把“没有落盘”拆成三个可验证的问题

排查一个用户的 PHPSESSID 时，常见误判有三种：文件还在，只是修改时间没有变化；请求读的是另一套 PHP-FPM 配置；前一个请求一直持有会话锁，后一个请求尚未走到写入阶段。三种现象在浏览器里都可能只表现为“登录状态不稳定”。

我更建议先做一次只读核对，把运行时配置、当前会话 ID 和保存目录同时记录下来：

这段输出的价值在于它来自实际处理请求的 SAPI。不要只看命令行里的 php -i，CLI 和 FPM 使用的 php.ini、池配置甚至扩展都可能不同。

session.lazy_write 改变的是写入时机，不是会话语义

PHP 手册对 session.lazy_write 的描述很具体：开启时，只有会话数据发生变化才重写。默认值为 1。因此，一个只读取 $_SESSION['uid'] 的页面，即使成功加载了会话，也可能让对应文件的 mtime 保持不变。

下面这个例子可以把“读到会话”和“产生写入”分开观察：

 $before,
    'after' => $_SESSION['last_seen'] ?? null,
    'lazy_write' => ini_get('session.lazy_write'),
], JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);

session_write_close();

连续访问不带 touch=1 的地址，业务上仍然能读到会话；带上参数后，值发生变化，关闭会话时才有新的内容需要写回。不要用“文件 mtime 没变”单独证明数据没有保存。

session.save_path 和文件处理器要在同一条链路上核对

默认的 files 处理器会把会话文件写进 session.save_path。目录存在，并不等于 FPM 工作进程能写入：需要同时检查运行用户、目录权限、磁盘空间和容器挂载。若配置使用了类似 2;/var/lib/php/sessions 的目录分层格式，还要确认分层目录已按处理器规则准备好。

# 在与 PHP-FPM 相同的运行环境中执行
php --ini
php -r 'echo session_save_path(), PHP_EOL;'
df -h /var/lib/php/sessions
namei -l /var/lib/php/sessions
find /var/lib/php/sessions -maxdepth 2 -type f -name 'sess_*' -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %p\n' | tail

这里的命令只适合核对环境，不要把目录权限直接改成全员可写。更稳妥的做法是找到 FPM 池实际用户，给它最小目录访问权限，并在变更后用一个临时会话 ID 做读写验证。

长请求为什么会把会话锁变成排队点

使用文件会话时，一个请求开启会话后，其他带着同一个会话 ID 的请求可能需要等待锁。典型场景是登录后页面同时发起多个接口请求，其中一个接口开启会话后又去调用外部服务，其他接口看起来就像“随机超时”。

如果后续还要更新会话，不能在关闭后继续假定 $_SESSION 会自动写回。应在确实需要修改时再次开启、修改、关闭，并尽量缩小这段临界区。这里的目标不是让所有请求都更快，而是让同一用户的请求不因无关的慢操作互相堵住。

用最小实验确认到底是内容、路径还是锁

可以准备两个临时地址：一个只读会话，另一个写入递增计数并故意延迟。用同一个浏览器会话并发访问，分别记录响应头、FPM 日志和会话文件变化。

1. 先访问只读地址，记录 session_id()、session_save_path() 和当前计数。
2. 再访问写入地址，确认计数变化后调用 session_write_close()，观察请求耗时。
3. 并发发起两个带同一 Cookie 的请求；如果一个请求在 session_start() 附近等待，优先缩短锁范围。
4. 在 FPM 容器内检查同一个 save_path，确认不是宿主机目录和容器目录看错。

验证完成后再决定是否调整 session.lazy_write。临时改成 0 可以帮助观察每次关闭是否重写，但它会增加写入，不应该被当作修复会话丢失的开关。更重要的是先恢复可观测性，确认写入的数据、保存位置和锁释放都符合预期。

常见问题

session.lazy_write=1 会不会导致登录状态丢失？

单独开启它不会。它只跳过未变化数据的重复重写；如果状态丢失，应继续检查 Cookie、会话处理器、保存目录、权限和多实例间的共享存储。

为什么改了 session.save_path 但请求仍写到旧目录？

通常是改错了 SAPI 配置，或 FPM 池配置覆盖了全局值。以实际请求输出的 session_save_path() 为准，并在配置变更后重载对应的 FPM 服务。

session_write_close() 调用后还能修改 $_SESSION 吗？

不要把关闭后的修改当作已经持久化。需要更新时重新开启会话、完成小范围修改，再立即关闭。

发布前检查清单

• FPM 实际运行时的 save_handler、save_path 和 lazy_write 已记录。
• 保存目录的挂载、磁盘空间、分层目录和最小权限已验证。
• 长请求在读取所需字段后及时关闭会话，没有把外部调用放在锁内。
• 至少用一个真实 Cookie 做过读、写、并发和重载后的回归测试。