“PHP 高并发 vs 非高并发” 的本质差异，不在代码写法，而在运行模型、资源调度、瓶颈边界。
普通业务用 FPM 足够，高并发需 Swoole/Worker 模型；但若不懂底层，高并发反而更容易崩。
一、运行模型：进程 vs 协程
| 维度 | 非高并发（FPM） | 高并发（Swoole） |
|---|---|---|
| 并发模型 | 多进程（每个请求 1 Worker） | 单进程多协程（1 Worker 处理 N 请求） |
| I/O 处理 | 同步阻塞（请求等待时 Worker 空闲） | 异步非阻塞（I/O 等待时切协程） |
| 内存占用 | 高（每 Worker 20–100MB） | 低（协程栈仅 8KB） |
| 启动开销 | 高（进程创建/销毁） | 低（协程切换微秒级） |
| 适用请求 | 短请求、无状态 | 长连接、I/O 密集 |
✅核心差异：
FPM：1 请求 = 1 进程（资源隔离，但浪费）
Swoole：1 进程 = N 协程（资源复用，但需小心状态）
二、瓶颈定位：完全不同的排查路径
非高并发（FPM）典型瓶颈：
- 进程数不足：
pm.max_children太小 → 502 错误； - 单请求慢：N+1 查询、大数组操作；
- 内存泄漏：
pm.max_requests未设 → Worker 内存累积。
排查工具：
top：看 Worker 进程 CPU/内存；ss -tan：看TIME_WAIT连接数；EXPLAIN：查慢 SQL。
高并发（Swoole）典型瓶颈：
- 协程阻塞：在协程中调用
sleep()、mysqli（同步阻塞）； - 连接池耗尽：Redis/MySQL 连接池小于并发数；
- 全局变量污染：协程间共享
$global_var。
排查工具：
swoole_server->stats()：看协程数、连接池状态；Coroutine::listCoroutines()：查挂起协程；strace：看是否陷入futex（锁竞争）。
三、资源消耗对比（实测数据）
| 指标 | FPM（PHP 8.2） | Swoole（5.0） |
|---|---|---|
| QPS（纯 echo） | 1500–2000 | 25000–30000 |
| 内存/1000 并发 | ~5GB（100 Worker × 50MB） | ~100MB（单进程） |
| CPU 利用率 | 高（进程切换开销） | 低（协程切换无系统调用） |
| 延迟（P99） | 50–100ms | 5–10ms |
💡关键：
Swoole 的 QPS 优势仅在 I/O 密集型场景；
CPU 密集型（如图像处理）两者无差异。
四、代码差异：看似相同，实则危险
1.全局变量（致命陷阱）
// FPM：安全（每个请求独立进程）$counter=0;$counter++;// Swoole：危险（协程共享进程内存）$counter=0;// 所有协程共享！$counter++;// 数据错乱✅Swoole 解法：用Coroutine::getContext()或局部变量。
2.同步阻塞函数
// FPM：可接受（仅阻塞当前 Worker）sleep(1);file_get_contents('http://api.com');// Swoole：灾难（阻塞整个进程！）sleep(1);// 所有协程挂起✅Swoole 解法：用Co::sleep(1)、Co::httpGet()。
3.数据库连接
// FPM：每次请求新建连接（可接受）$pdo=newPDO(...);// Swoole：必须用连接池$pool=newSwoole\Database\PDOPool(...);$pdo=$pool->get();// ... use ...$pool->put($pdo);五、调试方式：完全不同的体验
| 场景 | FPM | Swoole |
|---|---|---|
| 打印调试 | echo/error_log直接输出 | 需Swoole\Logger，避免echo混乱 |
| 断点调试 | Xdebug 支持良好 | Xdebug 不支持协程，需swoole_debug |
| 性能分析 | xhprof/Tideways | Swoole\Tracker或perf |
| 崩溃分析 | core dump简单 | 需gdb+swoole符号表 |
🔥Swoole 调试难点：
- 协程切换导致调用栈断裂；
- 全局状态难以追踪。
六、适用场景：不要为了高并发而高并发
| 场景 | 推荐模型 | 原因 |
|---|---|---|
| 传统 Web（CMS、电商） | FPM | 请求短、无状态、开发简单 |
| API 网关、微服务 | Swoole | 高 QPS、低延迟、连接复用 |
| WebSocket、长连接 | Swoole | FPM 无法维持长连接 |
| CPU 密集型（视频转码） | FPM + 队列 | Swoole 无优势，且调试复杂 |
✅决策原则：
先用 FPM，当 QPS > 1000 或需长连接时，再考虑 Swoole。
七、总结
| 维度 | 非高并发（FPM） | 高并发（Swoole） |
|---|---|---|
| 心智模型 | 请求隔离 | 协程协作 |
| 性能瓶颈 | 进程数、单请求效率 | 协程阻塞、连接池 |
| 开发难度 | 低（传统 PHP） | 高（需理解异步） |
| 运维复杂度 | 低 | 高（需监控协程） |
真正的高并发能力，
不是“会用 Swoole”，
而是“知道何时用、如何避坑、如何调试”。
盲目上 Swoole，
不如优化 FPM + 缓存 + 队列。
高并发是手段，不是目的。
