swoole更适合高并发、i/o密集、需协程抽象的场景；workerman更适合快速上线、跨环境部署、调试频繁或php经验强但c扩展经验弱的项目，二者无绝对优劣，只有匹配度差异。

面试时说“我用过 Swoole”基本等于没说，面试官真正想听的是：你解决过什么具体问题，为什么选 Swoole 而不是 Workerman 或原生 PHP-FPM，以及线上出过什么错、怎么定位的。

怎么讲清楚一个 Swoole 项目，而不是罗列技术点

别一上来就说“我用了 Swoole 4.8 + Coroutine + Channel”，先锚定业务场景。比如：“当时有个实时工单状态推送服务，QPS 300+，PHP-FPM 模型下平均延迟 1.2s，改用 Swoole\Http\Server 后压测稳定在 80ms 内”。

重点突出三个信息：

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

• 原始瓶颈在哪（比如连接数卡在 max_children、Redis 连接池打满、DNS 阻塞）
• 你动了哪几处关键代码（比如把 file_get_contents 换成 Co\Http\Client，把 new Redis() 改成从 Co\Channel 获取连接）
• 上线后可观测指标变化（server->stats() 里 connection_count 和 request_count 的比值是否趋近 1，slowlog 是否归零）

被问“Swoole 协程和 Go 协程区别”时，别背概念

直接说你踩过的坑更有效。比如：

• 协程不是万能的：我们曾用 Co\MySQL 查 10 万行数据，结果协程栈溢出，后来拆成每次查 500 行 + Co::sleep(0) 让出调度权
• 阻塞函数依然会卡住整个进程：比如没加 timeout 的 curl_exec（即使在协程里），必须换 Co\Http\Client
• isset($this->prop) 在协程间不安全：对象属性被多个协程同时读写，得用 Co\Channel 或 Swoole\Atomic 控制

如何解释“为什么不用 Workerman”

别贬低对手，聚焦你项目的实际约束：

• 需要 HTTP/2 或 WebSocket 子协议支持？Swoole\Http\Server 原生支持，Workerman 得自己解析帧
• 要热重载配置？swoole_reload() 可平滑 reload worker，Workerman 需发信号再手动 reload
• 依赖 Laravel Octane？它底层绑定 Swoole\Server 的生命周期，换其他框架成本高
• 但反过来，如果只是简单长连接透传，且团队熟悉 ThinkPHP + Workerman，那选 Swoole 反而是过度设计

真实项目里，最难的从来不是启动一个 Swoole\Server，而是协程上下文丢失、静态变量跨请求污染、以及 opcache + reload 导致的类定义不一致——这些细节，比背熟 API 更容易暴露你到底写没写过线上代码。