PHP 同一用户的多个请求为什么排队执行

如果同一个用户同时发起多个 AJAX 请求，却发现它们像排队一样一个接一个执行，优先检查 session_start()。PHP 会话通常需要先读取并锁定同一份会话数据，后续带着相同 Session ID 的请求只能等待锁释放。最常见的修复不是给 PHP-FPM 加进程，而是把会话的持有时间缩到最短：读完或写完 $_SESSION 后立即关闭，数据库查询、远程调用和文件处理放到关闭之后。

同一用户的请求排队，通常是 Session 锁造成的。只读用 session_start(['read_and_close' => true])，需要写入则在最后一次修改 $_SESSION 后调用 session_write_close()；但并发写同一字段时仍要保留业务层的冲突处理。

为什么同一用户的请求会在 session_start 排队

session_start() 会根据请求里的 Session ID 恢复会话。PHP 默认的文件 Session Handler 会在打开会话时锁住对应数据，目的是避免两个请求同时修改同一份序列化数据。于是，一个请求拿到锁后，即使它只是继续执行慢查询，另一个请求也可能卡在自己的 session_start()。

这个现象很容易被误判成“同一用户只能有一个 PHP-FPM 进程”。实际上，不同用户的请求仍可并行；被串行化的是使用相同 Session ID 的会话访问。典型触发场景是页面初始化时发出多个 AJAX 请求，其中一个接口启动 Session 后又调用外部服务，锁会一直持有到脚本结束。

先改会话边界：读完或写完立刻释放

不需要改 Session 的接口，可以直接读完并关闭：

 true,
]);

$userId = $_SESSION['user_id'] ?? null;
// 从这里开始执行查询或远程调用，不再占用会话锁

如果请求要写入状态，就在写入完成后显式关闭：

关键顺序是“取值或写值—关闭—慢操作”。如果慢操作的结果必须写回 Session，应先判断是否真的需要会话状态；确实需要时重新打开、修改、再次关闭，并把可能的并发覆盖作为单独问题处理。

关闭会话后哪些代码不能继续做

session_write_close() 不会让 PHP 中的 $_SESSION 变量消失，它只是把当前内容写回并释放存储锁。关闭后再给数组赋值，通常只改了当前请求内存里的副本，脚本结束时不会按预期更新刚才那份 Session。

排查时可以在 session_start() 前后记录耗时，并对照 PHP-FPM、数据库和下游服务的耗时。如果只有第二个请求在进入控制器前等待，而第一个请求的 Session 生命周期很长，基本就能定位到会话边界。

自定义 Session Handler 时要重新判断并发

如果项目通过 session_set_save_handler() 接入 Redis、数据库或其他存储，不要默认它们会自动提供与文件 Handler 相同的互斥语义。自定义 Handler 的 read、write 和 close 必须共同保证数据一致性：允许并发读取不等于允许并发写入。

可以先按这份清单检查：

• 读操作是否在不需要修改时尽快关闭会话；
• 同一 Session ID 的两个写请求是否可能后写覆盖先写；
• 超时、进程退出和写入失败时，锁或租约是否会释放；
• Session 中是否混入了本应放在数据库、缓存或任务表里的大对象。

如果只是解决 AJAX 并发，先缩短默认会话锁通常足够；如果业务要求两个请求同时更新同一份状态，就需要在存储层使用版本号、原子更新或明确的状态机，而不是简单地关闭锁。

常见问题

调用 session_write_close 后还能读取 $_SESSION 吗？

当前请求内通常还能读取，因为数组仍在内存中；但关闭后继续修改不会自动写回 Session。需要持久化的新值应重新打开并再次关闭。

只把 session_start 放到接口开头，为什么仍然很慢？

因为锁的释放点通常是脚本结束。只要接口在会话打开后执行了慢查询、远程调用或 sleep，同一用户的其他请求就可能在各自的 session_start 处等待。

read_and_close 能解决所有并发问题吗？

不能。它适合明确只读的请求；并发写入仍可能产生业务覆盖、顺序错乱或状态冲突，必须使用锁、原子更新或版本检查。

因此，遇到“同一用户请求排队”时先画出 Session 的打开、最后一次写入和关闭三个节点，再决定是否提前释放。会话锁解决的是数据一致性，慢业务则应在锁外完成。