swoole不是语法糖，而是将php从请求-响应拽入常驻内存的开关；用错场景、忽视生命周期、混用同步调用比不用更危险。
直接说结论：Swoole 不是“换个写法就能跑得更快”的语法糖，它是把 PHP 从请求-响应模型拽进常驻内存世界的开关——用错地方、没管好生命周期、混用同步阻塞调用，比不用还危险。
为什么 swoole_http_server 启动后修改代码不生效？
因为 Worker 进程常驻内存，PHP 文件只在启动时加载一次，后续所有请求都复用同一份已编译的脚本和变量空间。
- 热更新不是自动的，
max_request是最朴素但有效的兜底：设为 1000，Worker 处理完 1000 个请求后自动退出，Manager 进程拉起新 Worker，自然就加载了新代码 - 开发期可配合
inotify+kill -USR1信号实现软重启，但生产环境慎用——USR1 会触发所有 Worker 逐个 reload，期间仍有请求被旧进程处理 - 绝对不要在
onRequest回调里include或require动态文件，这会导致 opcode 缓存失效、类重复定义、静态变量污染
Co::sleep() 和 sleep() 在 Swoole 里为什么不能混用？
sleep() 是同步阻塞系统调用，会挂起整个 Worker 进程；而 Co::sleep() 是协程让出控制权，仅暂停当前协程，其他协程照常运行。
- 现象：在协程函数里误用
sleep(1)，整个 Worker 卡死 1 秒，100 个并发请求全排队等待 - 场景：定时轮询数据库状态、模拟网络延迟、限流器中的等待逻辑，必须用
Co::sleep() - 注意：
Co::sleep(0)是主动让出 CPU 的常用技巧，用于避免协程饥饿，但别滥用——频繁让出会增加调度开销
WebSocket 长连接下如何安全清理用户上下文？
不能只依赖 onClose 回调——客户端异常断网、NAT 超时、代理中断都不会触发它，必须叠加心跳与空闲检测。
-
onClose只处理明确的 close 帧或 TCP FIN，要补上onPing/onPong心跳超时逻辑（例如 30 秒无 pong，主动$server->close($fd)） - 用户数据（如对话 history、临时 token）必须绑定
$fd存到Swoole\Table或 Redis，且在onClose和心跳超时分支里都做清理 - 别把上下文存在全局数组或 static 变量里——Worker 进程复用时，前一个用户的残留数据可能污染下一个请求
协程里调用 PDO 查询为什么容易卡住？
PDO 默认是同步阻塞的，即使在协程里调用，也会阻塞当前协程，且无法被 Co::sleep() 中断；更糟的是，MySQL 连接若未设置 PDO::ATTR_TIMEOUT，可能无限等待。
- 必须用连接池：通过
Swoole\Coroutine\MySQL或hyperf/database等封装好的协程 MySQL 客户端，它们底层调用mysql_real_connect的非阻塞模式 - 手动封装 PDO 不现实——要自己处理 socket 非阻塞、SSL 握手、字符集协商，成本远高于换组件
- 如果必须用 PDO（比如 legacy 代码），至少加
['options' => [PDO::ATTR_TIMEOUT => 3]]，并用Co::create()包一层，但仍是妥协方案
真正难的不是写对那几行 go() 或 Channel，而是想清楚每个变量、每条连接、每次 sleep 的生命周期边界在哪——Swoole 把“谁该什么时候释放”这个问题，从框架隐式管理，推到了你面前。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
