PHP-FPM应按请求特征选static或dynamic：短接口用static省开销，长耗时用dynamic防阻塞；需配连接池、Redis原子操作、避免Swoole硬迁移，并监控周边瓶颈。
PHP-FPM 进程模型选型直接影响并发上限
用 static 还是 dynamic？不是配置越多越快，而是得看请求特征。短平快接口（比如 API）适合 static，省去进程启停开销；但长耗时操作（如文件上传、PDF 生成）用 static 容易把所有 worker 占满，新请求直接排队等死。
-
pm = static：设pm.max_children要严格匹配服务器内存，每个 PHP 进程常驻约 20–40MB，超了会触发 OOM Killer 杀进程 -
pm = dynamic：重点调pm.start_servers、pm.min_spare_servers、pm.max_spare_servers，避免频繁 fork/destroy 进程——这本身就会吃 CPU - 别碰
ondemand模式：高并发下冷启动延迟明显，pm.process_idle_timeout一到就杀进程，再有请求又得重建，雪上加霜
MySQL 连接池缺失是 PHP 高并发最常踩的坑
PHP 默认不带连接池，mysqli 或 PDO 每次 new 都建新 TCP 连接，数据库端很快堆满 Too many connections。这不是 PHP 慢，是连接没复用。
- 用
PDO时必须显式开启持久连接：new PDO($dsn, $user, $pass, [PDO::ATTR_PERSISTENT => true])，否则PDO::ATTR_PERSISTENT设了也白设 - 持久连接不等于“永远不关”，它在请求结束时归还给连接池，但若脚本里
unset($pdo)或异常退出，连接可能被标记为“损坏”而丢弃 - MySQL 服务端的
wait_timeout（默认 8 小时）和 PHP 的连接空闲时间要对齐，否则会出现MySQL server has gone away
Redis 用不好，缓存反而成瓶颈
高频写场景下，set 和 get 看似简单，但没注意原子性或序列化方式，很容易引发缓存击穿或数据错乱。
- 别用
get+set手动双检：竞态下多个请求同时发现缓存为空，全去查 DB，瞬间压垮后端——改用set($key, $val, ['nx', 'ex' => 60])原子写入 - PHP 序列化默认用
serialize()，和 Python/Node 不兼容；跨语言项目务必统一用json_encode()+json_decode()，且注意null和空数组解码差异 - 大量小 key 别用单个
get循环查，改用mget；但mget返回数组顺序固定，别靠下标猜字段名，要用array_combine($keys, $vals)对齐
协程不是 PHP 原生能力，别硬套 Swoole 语法到传统 FPM
看到“高并发”就想上 Swoole？先确认你的代码是否真能适配。FPM 下写的 file_get_contents、sleep、mysqli_query 在 Swoole 协程环境里会阻塞整个进程，除非你换 co\curl、Swoole\Coroutine\MySQL 等异步替代品。
立即学习“PHP免费学习笔记（深入）”；
- 已有项目迁移前，先跑一遍
vendor/bin/phpstan+ 自定义规则，扫描出所有同步 I/O 调用点 -
Swoole\Http\Server和PHP-FPM的生命周期完全不同：没有$_SESSION、$_COOKIE自动解析，需手动从$request->cookie取 - 别在协程里用
global或静态变量存请求上下文，协程切换后值会串——改用Co::getContext()或ApplicationContext
并发量上来之后，真正卡住的往往不是 PHP 本身，而是 MySQL 连接数、Redis 连接超时、DNS 解析阻塞这些“周边环节”。盯着 ab 或 wrk 的结果看平均响应时间没用，得抓 strace -p $(pgrep php-fpm) -e trace=connect,sendto,recvfrom 看哪一步在等。
