PHP 协程与 Swoole：什么时候才值得放弃 FPM

结论：只有当你的瓶颈是「高并发 + 大量 I/O 等待 + 需要长连接或常驻状态」三条同时成立时，才值得放弃 PHP-FPM 改用 Swoole 协程；否则 FPM 依然是性价比最高、最不容易翻车的选择。

FPM 的成本模型：一次请求，一切重来

PHP-FPM（FastCGI Process Manager，PHP 官方推荐的进程管理器）的本质是「每请求一进程」：请求进来时初始化框架、连数据库、跑逻辑，请求结束把内存全部还给系统。代价是每次都要重复付「框架启动 + 数据库握手」这两笔固定开销，收益则是天然的隔离性——内存泄漏会被进程回收吞掉，静态变量不会跨请求串味，任何老代码、任何扩展拿来就能跑，部署就是传文件。

换句话说，FPM 用「重复初始化」买了「确定性」。这个交易在绝大多数站点上是划算的，因为那些固定开销通常只有几十毫秒，而你的瓶颈往往根本不在这里。

Swoole 实际换来的只有三样东西

Swoole 是 PHP 的协程与常驻内存扩展，它让进程启动一次后一直活着，在 I/O 等待时挂起当前协程去处理别的请求。算下来它只带来三块收益：一是省掉框架初始化（常见框架单次 20–80ms）；二是连接池复用，省掉 MySQL/Redis 每次 1–5ms 的 TCP 握手与鉴权；三是协程调度把「等 I/O」的时间变成并发度，单进程可挂起成百上千个协程。

所以判断标准很简单：你的响应时间到底花在哪。如果压测显示 CPU 没跑满、进程也没排满，请求时间却被外部 API、数据库、远程 HTTP 调用吃掉了七八成，那才是协程的主场。

代价不是换运行方式，是换一套编程约束

上 Swoole 之前必须想清楚，你放弃的是 FPM 的全部「不需要操心」：全局变量和静态变量会跨请求污染，上一请求的用户数据可能漏给下一个人；内存泄漏不再自愈，得自己盯常驻进程的内存曲线；任何阻塞调用（sleep、file_get_contents、同步 HTTP SDK）都会卡死整个进程，第三方 SDK 必须逐个验证；Xdebug 与部分扩展在协程下行为不同，调试难度陡增；代码热更新失效，改完必须 restart 进程，部署链路要额外引入进程守护与优雅重启。

结论：Swoole 的迁移成本主要在「代码能不能在常驻进程里安全运行」，而不在「装个扩展」，这部分工作量常被严重低估。

动手之前，先用这张清单卡一遍

命中两条以上再考虑迁移：单请求超过 70% 时间在等 I/O；业务需要 WebSocket、SSE 长连接或实时推送；单机 QPS 长期高于 2000–3000 且靠加机器扩容已经很不经济；单个请求内反复建立多次数据库或 Redis 连接。

如果只命中「框架启动慢」，答案是不用换——先做这六件事：开启 OPcache 并在生产环境设 opcache.validate_timestamps=0；把慢 I/O 挪出请求周期，改走队列异步化；上加 Redis 缓存与页面级缓存；治理慢查询、补索引、必要时读写分离；按 pm=dynamic 调优 FPM 进程数并把 PHP 升到 8.x；静态资源交给 Nginx 或 CDN 直出。

结论：把 FPM 之上的优化空间榨干之前，谈进程模型都是过早优化。

折中路线：局部常驻，而不是全站重写

更务实的做法是拆而不是换。要么用 RoadRunner、FrankenPHP 这类常驻应用服务器，它们用 Go/C 写宿主进程，原有 PHP 代码基本不用改；要么只把 WebSocket、消息推送这类长连接服务单独用 Swoole 部署，主站继续跑 FPM，两边通过 Redis 通信。迁移时先挑一个非核心的高并发接口灰度试点，用真实压测数据而不是感觉来决策。

论坛类站点：几乎没理由上 Swoole

Clara BBS 就是典型反例。它是一款无框架轻量级 PHP 社区论坛系统，环境要求 PHP 7.4-8.5 + MySQL 5.7+，不需要 Composer、不需要命令行、没有编译缓存，插件保存即生效。这种设计前提本身就是传统 FPM 模型：请求短、逻辑轻、读多写少。

论坛的真实瓶颈通常先出现在数据库查询次数、图片附件上传与磁盘 IO 上，而不是进程模型。这类场景靠缓存、索引、CDN 和上传限制就能扛住相当规模的流量，为此把整套代码搬进常驻进程，换来的是运维复杂度和难以排查的跨请求污染——收益和风险倒挂。

回到标题：只有当 I/O 等待才是你真正的成本中心、且你需要长连接和连接复用时，放弃 FPM 才划算；其他情况下，先把 OPcache、缓存、队列和 SQL 这几件事做完，收益更快也更安全。