PHP高并发核心是避免隐性串行点：合理配置PHP-FPM进程数防OOM，禁用PDO持久连接防MySQL连接数溢出，替换flock文件锁为Redis，改用Redis存储Session，并识别同步I/O瓶颈。
PHP 本身不支持真正的并发请求处理（比如像 Go 的 goroutine 或 Node.js 的 event loop），它依赖 Web 服务器（如 Apache、Nginx）和 SAPI（如 FPM）模型来应对高并发——关键不是“PHP 怎么并发”，而是“怎么让 PHP 在高并发下不崩、不卡、不丢数据”。
PHP-FPM 的 pm.max_children 设定不合理，直接导致 502/504
这是线上最常触发的故障点：Nginx 报 502 Bad Gateway 或 504 Gateway Timeout，日志里出现 upstream sent too big header 或 recv() failed (104: Connection reset by peer)，大概率是 PHP-FPM 进程数撑爆了。
-
pm.max_children不是越大越好——每个 child 占用内存约 20–50MB（取决于扩展和代码），设成 100 可能吃掉 3GB 内存，OOM killer 会直接杀掉 fpm master 进程 - 合理值 ≈
可用内存 × 0.8 ÷ 单进程平均内存，用php-fpm -i | grep 'memory_limit'和ps aux --sort=-%mem | grep 'php-fpm' | head -5实测更准 - 配合
pm.start_servers/pm.min_spare_servers使用静态模式（pm = static）比动态模式（pm = dynamic）更可控，避免突发流量时 fork 延迟
数据库连接池缺失，PDO::ATTR_PERSISTENT 用错反成瓶颈
很多人以为开启持久连接就能抗并发，结果发现 MySQL 连接数暴涨、Too many connections 频发，甚至主从延迟飙升。
-
PDO::ATTR_PERSISTENT => true是按 PHP-FPM worker 进程复用连接，不是跨进程共享——100 个 fpm 子进程就可能建 100 个长连，远超max_connections - 真正需要的是连接池（如 ProxySQL、MySQL Router），或改用短连 + 连接复用中间件（如 Swoole 的
Swoole\Coroutine\MySQL） - 若坚持用 PDO 持久连接，必须同步调低
wait_timeout（MySQL 侧）和pm.max_requests（PHP-FPM 侧），防止 stale connection 积压
文件锁、flock() 和 file_put_contents(..., LOCK_EX) 在高并发下变成串行瓶颈
用文件记录计数器、写日志、临时缓存时，flock() 看似安全，实则把并发请求强行变单线程——1000 QPS 可能只剩 50 QPS 实际写入速度。
立即学习“PHP免费学习笔记（深入）”；
-
flock()是阻塞式，没有超时控制；file_put_contents($f, $d, FILE_APPEND | LOCK_EX)同理，写慢盘时锁等待雪球效应明显 - 替代方案优先级：Redis（
INCR/LPUSH） > 数据库事务（带SELECT ... FOR UPDATE） > 本地文件（仅限低频、非关键场景） - 如果必须用文件，改用无锁追加（
file_put_contents(..., FILE_APPEND)不加LOCK_EX），再靠后续异步合并或校验修复一致性
Session 默认文件存储在高并发下严重拖慢响应
默认 session.save_handler = files 会让所有请求竞争同一个 session 文件锁，尤其当页面执行时间稍长（比如含 API 调用），后续请求全卡在 session_start() 上。
- 立刻切到 Redis：设置
session.save_handler = redis和session.save_path = "tcp://127.0.0.1:6379?database=1"，无需改代码 - 若用 Memcached，注意其 key 长度限制（250 字符），PHP 生成的 session_id 可能超长，需配
memcached.sess_locking = Off（但会丢失并发写 session 的原子性） - 对只读接口（如纯展示页），加
session_write_close()尽早释放锁，避免 session 文件被长时间持有
真正难的不是配置几个参数，而是识别哪条路径正在成为隐性串行点——可能是你没意识到的 file_get_contents('http://') 同步调用，也可能是 Composer 自动加载里的 stat() 系统调用。高并发下的性能毛刺，往往藏在“看起来无害”的同步 I/O 里。
