PHP session默认阻塞并发请求，因session_start()后持有文件写锁，需调用session_write_close()或session_read_and_close()及时释放锁才能实现实时输出。
PHP 输出时 session 默认会阻塞后续请求
是的，只要 session_start() 被调用且 session 文件未关闭，PHP 就会持有该 session 文件的写锁（flock），导致同一用户的其他并发请求被阻塞，直到当前脚本结束或显式释放锁。
这在实时输出场景（比如用 flush() + ob_flush() 推送进度）中尤为明显：用户打开页面后，再开一个标签页访问同域名下另一个 PHP 页面，会卡住几秒甚至更久，直到第一个请求完成。
- 锁发生在
session_start()后、session_write_close()前 - 即使你没写入 session（如只读
$_SESSION['x']），默认仍以读写模式打开，触发写锁 - 使用
session_read_only（PHP 7.0+）可避免锁，但需配合session_start(['read_and_close' => true])或手动控制
如何安全地实时输出又不锁 session
核心思路是：尽早释放 session 锁，但保留对 $_SESSION 的读取能力（如果需要），再进行耗时输出。
- 如果不需要修改 session：调用
session_start()后立刻执行session_write_close() - 如果需要读 session 数据：先读取所需值到局部变量，再关锁，后续输出中不再访问
$_SESSION - 不要在
session_write_close()后调用$_SESSION写操作，否则会报错或静默失败
示例：
立即学习“PHP免费学习笔记（深入）”；
";
ob_flush();
flush();
usleep(100000);
}
?>
session_read_and_close() 和 session_write_close() 有啥区别
二者都释放锁，但语义和行为略有不同：
-
session_write_close()：明确表示“我要结束 session 写入”，会尝试写回变更（即使没改也触发一次 write 回调），然后释放锁 -
session_read_and_close()（PHP 7.2+）：更轻量，仅读取并立即关闭，跳过 write 流程，适合纯读场景 - 两者都不能在关闭后再写
$_SESSION；若后续还需写，只能重新session_start()（但会再次加锁）
注意：session_read_and_close() 不是所有 PHP 版本都支持，线上环境建议优先用 session_write_close() 并确保无写操作。
为什么 output buffering 和 flush 不起作用还卡着
常见误区是以为开了 ob_* 和 flush() 就能实时推送，却忽略了 session 锁才是根本瓶颈。即使输出层通畅，第二个请求仍会被 session 文件锁拦在网关外。
- 验证是否锁导致：用两个浏览器标签页，一个访问带
session_start()的长脚本，另一个访问仅session_start(); echo 'ok';的短脚本 —— 后者会等到前者结束才响应 - Apache + mod_php 下，锁是进程级的；PHP-FPM 则是 worker 进程间通过文件系统锁同步
- Nginx + PHP-FPM 组合中，客户端可能因缓冲（如 proxy_buffering）收不到分块响应，需额外配
fastcgi_buffering off和chunked_transfer_encoding on
session 锁是隐式发生的，不报错、不警告，最容易被当成网络或输出配置问题排查半天。
