企业官网建设流程全解析

“PHP 高并发 vs 非高并发” 的本质差异，不在代码写法，而在运行模型、资源调度、瓶颈边界。
普通业务用 FPM 足够，高并发需 Swoole/Worker 模型；但若不懂底层，高并发反而更容易崩。

一、运行模型：进程 vs 协程

✅核心差异：
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（锁竞争）。

三、资源消耗对比（实测数据）

💡关键：
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);

五、调试方式：完全不同的体验

🔥Swoole 调试难点：

• 协程切换导致调用栈断裂；
• 全局状态难以追踪。

六、适用场景：不要为了高并发而高并发

✅决策原则：
先用 FPM，当 QPS > 1000 或需长连接时，再考虑 Swoole。

七、总结

真正的高并发能力，
不是“会用 Swoole”，
而是“知道何时用、如何避坑、如何调试”。

盲目上 Swoole，
不如优化 FPM + 缓存 + 队列。
高并发是手段，不是目的。