session_start()卡顿数百毫秒的根源是文件存储下的会话文件独占锁，而非函数本身慢；并发请求需排队等待锁释放，调用session_write_close()可立即释放锁，或改用Redis等无锁存储后端。
session_start() 为什么一卡就是几百毫秒
不是函数本身慢，是 PHP 默认用文件存 session 时，session_start() 会独占锁住那个 sess_* 文件。只要一个请求还没结束（比如在等 cURL、数据库查询、或执行耗时逻辑），其他所有需要读写 session 的并发请求就只能排队等着——哪怕它们只读不写。
常见现象：session_start() 调用后，后续代码明显延迟；高并发下出现 502 或请求超时；strace 看到大量 flock 等待；iotop 显示磁盘 I/O 并不高，但响应就是上不去。
- 锁持续时间 = 从
session_start()开始，到脚本结束 或 显式调用session_write_close()为止 - 即使你只读
$_SESSION，PHP 仍默认加写锁（为防后续可能写入） - 挂载在 Docker volume 或 NFS 上的 session 目录，锁争用会更严重
session_write_close() 不是可选，是必调
只要你在 session_start() 后完成了对 $_SESSION 的读写操作，且后续逻辑不依赖 session（比如发邮件、调第三方 API、生成 PDF），就必须立刻调用 session_write_close() 释放文件锁。
错误写法：
session_start();<br>$_SESSION['last_visit'] = time();<br>// 这里开始做耗时操作，锁还一直占着<br>sleep(2);<br>echo 'done';
立即学习“PHP免费学习笔记（深入）”；
正确写法：
session_start();<br>$_SESSION['last_visit'] = time();<br>session_write_close(); // ✅ 锁立刻释放<br>sleep(2); // 其他请求现在可以进来了<br>echo 'done';
- 调用
session_write_close()后，$_SESSION变量仍可读，但不能再写（写无效） - 不要在
session_write_close()后再赋值$_SESSION['x'] = ...，那不会保存 - 如果后续还有 session 操作（比如跳转前再设个状态），得重新
session_start()
换掉 files handler 是根治方案
文件锁本质是设计限制，不换存储后端，永远绕不开排队。Redis 是目前最稳妥的选择：无锁、原子、内存级响应。
改 php.ini：session.save_handler = redissession.save_path = "tcp://127.0.0.1:6379?database=2"
（确保已安装 php-redis 扩展）
- MySQL / Memcached 也能用，但 Redis 对 session 场景更友好（TTL 自动清理、无连接池烦恼）
- 别用
session_set_save_handler()手写文件操作类——自己实现锁和序列化只会放大问题 - 上线前确认
session.gc_maxlifetime和 Redis 的过期时间一致，否则会话提前丢失
哪些情况不能靠 session_write_close() 解决
有些场景，即使你马上关 session，也救不了速度——因为问题不在锁，而在别的地方。
典型误判点：
- 开启了 xdebug：它会让所有 PHP 函数调用变慢，session_start() 只是第一个背锅的
- session.save_path 指向了权限不对或空间不足的目录：PHP 会静默失败并 fallback 到临时路径，日志里可能只有 warning
- 使用了 session.use_strict_mode = 0 + 频繁伪造 PHPSESSID：PHP 会反复尝试读不存在的 session 文件
- 先运行
php -i | grep -E "(session|save_path|handler)"确认实际生效配置 - 检查
error_log里有没有Failed to write session data或open_basedir restriction - 用
lsof -p $(pgrep php-fpm) | grep sess看是否真有大量 session 文件被长期占用
session 文件锁问题表面看是“怎么快点启动”，实际是“什么时候该放手”。很多人卡在调了 session_write_close() 还没效果，往往是因为没意识到：锁不是在 session_start() 时加的，而是在它之后第一次真正访问 $_SESSION 时才加的——所以空跑一次 session_start() 再关，根本没意义。
