根本原因是文件锁导致请求串行化：session_start()默认加独占锁，同一会话ID的多个并发请求必须排队等待锁释放，即使只读也会阻塞，且锁持续至脚本结束或显式调用session_write_close()。
PHP 8.3 使用文件存储 session 时，高并发下读写缓慢的根本原因不是 PHP 版本问题，而是文件锁（flock(LOCK_EX)）导致请求串行化——同一会话 ID 的多个并发请求必须排队等待锁释放。这不是“慢”，是阻塞。
为什么 session_start() 一调用就卡住？
这是最典型的症状：多个 AJAX 请求或页面内资源（如图片、接口）复用同一会话 ID 时，第二个请求在 session_start() 处挂起数秒甚至超时。根本原因是：
-
session_start()默认以独占锁打开sess_*文件，且锁持续到脚本结束或显式调用session_write_close() - 哪怕你只读
$_SESSION、完全不写，锁依然持有 - Linux 下小文件频繁
flock在 ext4 上有明显内核级延迟，尤其容器环境（如 Docker 挂载卷）更甚
session_write_close() 必须在哪儿调用？
不是“建议”，是硬性操作节点：只要完成对 $_SESSION 的读/写，且后续逻辑不依赖会话修改（比如发邮件、调第三方 API、生成图片），立刻调用：
session_start(); $user_id = $_SESSION['user_id'] ?? null; // ✅ 此刻已读完，无需再碰 $_SESSION session_write_close(); // ❌ 后面这些操作都不该被 session 锁拖住 send_notification($user_id); generate_thumbnail($image_path); sleep(2); // 模拟耗时任务
注意：session_write_close() 后不能再读写 $_SESSION，否则会静默失败或触发警告；若后续还需读，只能重新 session_start()（但要承担再次加锁成本）。
立即学习“PHP免费学习笔记（深入）”；
抓取并分析 OpenClaw JSONL 会话日志，重建并回填代理记忆文件。适用于：(1) 模型切换后记忆不完整，(2) 验证记忆覆盖度，(3) 重建丢失记忆，(4) 通过 cron/heartbeat 自动同步每日记忆。支持简单提取及基于 LLM 的叙事摘要，并自动清理敏感信息。
哪些请求根本不需要 session_start()？
大量静态资源、无状态接口、健康检查端点、图片上传预检等场景，压根不该碰 session。常见误用：
- 前端所有请求都带
PHPSESSIDCookie，后端统一session_start()中间件（如某些框架默认行为） - API 接口返回 JSON，但因鉴权逻辑粗放，对 OPTIONS/PREFLIGHT 或公开接口也启动 session
- favicon.ico、robots.txt 等静态路径被路由到 PHP 脚本，意外触发
session_start()
解决方案：在 Web 服务器层拦截（Nginx/Apache）或入口脚本中做路径白名单判断，跳过 session_start()。
session.save_path 目录本身也有坑
即使加了 session_write_close()，如果 session.save_path 指向 NFS、Docker volume 或低速磁盘，单个文件锁的争用虽缓解，但 opendir()/readdir() 扫描会话目录（如垃圾回收触发时）仍会卡住整个进程。关键检查点：
- 确认
session.save_path是本地高速磁盘（如/var/lib/php/sessions），而非/tmp（可能被 tmpfs 限制大小或清理） - 避免使用 root 用户运行 PHP-FPM 写入该目录——权限问题会导致锁失败后重试，加剧延迟
- 定期清理过期 session：
find /var/lib/php/sessions -name 'sess_*' -mmin +24 -delete（比 PHP 自带 GC 更可控）
真正棘手的是：当用户量稳定在 100+ 并发且持续增长时，文件存储的扩展性已到极限。此时迁移至 redis 不是“优化选项”，而是必选项——它绕过了文件系统和锁，把 session 变成一次内存键值操作。别等超时报警才动手。
