PHP session 锁导致接口排队：同一会话并发请求的定位与处理

开发中常碰到这类场景：一个接口负责刷新用户信息，另一个接口负责拉取业务列表，两个请求逻辑上完全互不相关，却在 PHP-FPM 日志里排成了整整齐齐的串行队列。挨个排查把慢原因从数据库追到业务代码都没找到头绪，真正卡住它们的很可能是同一个 PHP session 文件锁。

先用两个请求复现排队现象

把问题缩到一个会话和两个入口：/profile.php 读取登录用户后故意处理一段时间，/notifications.php 只读取未读数。两个请求使用同一个浏览器 Cookie，同时点击时，如果第二个请求总是在第一个请求结束后才进入 PHP 代码，数据库并不是第一嫌疑。

给第二个请求的入口处加一条进入日志即可。用浏览器网络面板比较两个请求的“等待”时间和“响应”时间：如果第一个请求约 800 毫秒，第二个请求也稳定延迟接近这段时间，而且第二个入口日志直到第一个请求结束后才出现，锁等待就有了直接证据。

为什么 session_start 会把请求串起来

使用默认文件保存器时，PHP 会根据会话 ID 找到对应文件。session_start() 读取数据后通常会保持会话处于打开状态，脚本结束或显式关闭时才写回并释放锁。于是，耗时的模板渲染、远程调用或文件处理如果放在会话打开期间，同一会话的另一个请求只能等待。

这里的关键不是“请求是否访问了同一个变量”，而是它们是否使用了同一个会话存储。两个接口即便读的是完全不同的键，也可能因为共享会话锁而排队；换一个浏览器或无 Cookie 请求，现象往往就不再出现。

最小改法：读完就释放，写入留在前面

如果接口只需要读取会话中的用户编号、租户编号或语言设置，可以在读取完成后显式关闭会话，再做慢操作：

关闭动作的价值是缩短会话锁的持有时间，而不是让数据库查询变快。改完后重新发起同会话并发请求，应该看到第二个入口日志更早出现；如果它仍然等待，再查数据库连接池、反向代理和 PHP-FPM worker 是否存在新的瓶颈。

哪些代码不能提前关闭 session

登录、退出、刷新 CSRF token、购物车写入、权限切换等流程会修改会话。先关闭再写入，往往只改了当前请求内存中的数组，脚本结束时并不会按预期写回文件。更稳妥的顺序是先完成所有会话更新，再关闭：

session_start();
$_SESSION['user_id'] = $userId;
$_SESSION['csrf_token'] = bin2hex(random_bytes(16));
session_write_close();

// 不再写 $_SESSION；后续工作不占用会话锁

如果后续流程必须多次更新会话，就不要把“提前释放”当成固定模板。可以把慢的非会话工作移到关闭之后，或者重新设计状态存储；不要为了消除等待而牺牲登录态、权限态和订单状态的一致性。

用时间线确认改动真的生效

验证时保留三类信息：请求开始和结束时间、调用 session_start 与 session_write_close 的日志、同一会话下的请求标识。一次请求变快不能证明问题解决，至少要重复同会话并发和不同会话对照。

• 同一会话并发：关闭前慢操作会出现明显串行，关闭后进入业务代码的时间应靠近。
• 不同会话并发：不应被同一个会话文件锁影响，用来区分全局资源瓶颈。
• 会话写入流程：登录或购物车更新后重新发请求，确认状态仍然存在。

常见问题

session_write_close 会清空 $_SESSION 吗？

不会，它会把当前会话数据写回并关闭本次会话访问；关闭后继续修改数组不能指望自动持久化。

只读接口也一定要关闭 session 吗？

如果接口后面有明显的慢操作，而且同会话并发等待已被证实，提前关闭通常值得做；纯短请求的收益可能很小。

换成 Redis session 就不会排队了吗？

不一定。具体锁行为取决于保存器实现和配置，存储换了不代表会话访问自动变成无锁并发，仍应通过时间线和官方文档核对。

关闭 session 后还需要再次 session_start 吗？

只有后续确实要读取或写入会话时才考虑重新打开；反复打开会重新引入锁，也让并发边界更难判断。

落地清单

先用同一 Cookie 复现，再定位会话打开到关闭的时间范围；只读接口读取必要字段后调用 session_write_close()；写入型流程在关闭前完成状态更新；最后用同会话、不同会话和状态回读三组测试确认结果。这样处理，既能消掉无谓的会话排队，也不会把登录态问题藏到下一次请求。