Swoole简历需突出真实调优经验：明确写出swoole_http_server配置、协程MySQL连接池参数、Table结构、压测工具与环境、监控方式、框架集成钩子点、热更新信号处理及版本兼容细节。
PHP Swoole 开发者简历不是堆砌“高并发”“协程”这些词就能出彩的——面试官一眼就能分辨出是真用过 swoole_http_server 调优过 QPS，还是只在本地跑过 php server.php 启个 demo。
突出你真正调过、压过、修过的 Swoole 组件
招聘方最常看到的简历问题：写“熟悉 Swoole”，但项目里只有 Swoole\Coroutine 启几个 go，没提上下文切换开销、没提 defer 或 waitGroup 怎么控生命周期。这不算 Swoole 工程经验。
- 把
swoole_http_server写成核心模块时，必须带参数：比如是否启用enable_static_handler、static_handler_locations怎么配、静态资源到底走没走 Swoole（还是被 Nginx 拦了） - 写协程 MySQL，得说明用的是
Swoole\Coroutine\MySQL还是co::mysql（已废弃），连接池怎么建、maxIdleTime设多少、有没有遇到ERRNO 104（连接超时）后怎么兜底 - 如果用过
Swoole\Table，别只写“用于共享内存”，要写清 key 结构（比如uid:12345）、字段类型（string[64]还是int）、是否配合onWorkerStart做预加载
性能数字不能编，但可以诚实写“从 X 到 Y”的过程
“QPS 提升 300%”这种话没人信；但“日均 20 万请求的订单通知服务，将 swoole_timer_tick 改为 swoole_timer_after + 消息队列延迟消费后，CPU 占用从 92% 降到 41%”就具体可信。
- 压测工具要写实：是用
ab、wrk还是自研脚本？并发数多少？测试环境 CPU/内存配置？ - 对比项必须同维度：比如改了
worker_num和task_worker_num配比后，看的是task_ipc_mode为 2（msgqueue）时的吞吐，而不是和之前task_ipc_mode=1（pipe）混着比 - 监控数据来源要可追溯：是靠
swoole_get_stats()定时采集，还是接入了 Prometheus 的swoole_exporter？
别让“Swoole”变成简历里的孤立词
纯 Swoole 项目极少。真正值钱的是你如何让它和现有体系咬合：比如 Laravel 里怎么桥接 Swoole\Http\Server，而不是另起一套路由；又比如 Redis 是用 Swoole\Coroutine\Redis 还是 predis + go 封装，为什么选这个方案。
立即学习“PHP免费学习笔记（深入）”；
- 写框架集成时，明确写出钩子点：比如在 Laravel 的
AppServiceProvider@register里启动Swoole\Server，还是用Runtime::enableCoroutine()把整个 FPM 请求协程化 - 写热更新，别说“支持平滑重启”，要写清信号触发的是
kill -USR1还是kill -SIGUSR1，worker 进程退出前有没有等onFinish回调完成、task是否设了finish_timeout - 如果做过进程模型调试，直接写：用
strace -p {pid}抓到epoll_wait长时间阻塞，最后定位到某次curl_exec没设CURLOPT_TIMEOUT_MS
最常被忽略的一点：Swoole 版本兼容性细节比语法更重要。比如 Swoole\Coroutine::create 在 4.8.0+ 已废弃，替换成 go；又比如 Channel 的 pop 方法在 5.0 里默认会 throw 异常而非返回 false——这些不写进简历，技术面第一轮就可能卡在版本认知上。
