Swoole基础进阶之协程篇

如果你已经能用 Swoole 起一个常驻进程、注册几个事件回调，却在遇到「协程」两个字时心里发虚，这门课就是冲这个缺口来的。Swoole 4.x 之后，协程不再是一个可选的高级特性，而是写业务代码时的默认运行方式——你调用 MySQL、Redis、HTTP 客户端，背后跑的都是协程调度。不把这层搞明白，代码能跑，但一压测就出问题，一出问题就不知道从哪查。

先确认你是不是这门课的目标读者

这门课假定你已经写过 Swoole 的传统异步代码，至少清楚 onReceive、onRequest 这类回调是怎么被触发的，也踩过回调嵌套的坑。如果这些还没有，建议先补 Swoole 基础，否则协程部分会听着像天书。

反过来，如果你现在的状态是下面任意一种，那这门课对得上：

• 知道协程是「用户态线程」，但说不清它在 Swoole 里到底由谁调度、什么时候切换；
• 写惯了同步代码，看到 go、Co\run、defer 这些写法，不确定该在哪加、加了会不会有副作用；
• 线上服务 QPS 上不去，怀疑和协程用法有关，但拿不出判断依据；
• 面试被问到「协程和进程、线程的区别」「协程里的阻塞调用会怎样」，答得含糊。

协程不是语法糖，是运行时的换血

很多人对协程的误解，是把它当成一种更简洁的异步写法。不是。协程改变的是「代码在哪里暂停、由谁恢复」这件事。

这门课基于 Swoole 4.2.x 展开，重点会落在几件具体的、能上手验证的事情上：协程是怎么被创建和调度的，遇到 IO 时协程挂起和恢复的时机，以及为什么同一个进程里能同时跑成百上千个协程而不会把栈撑爆。

更关键的是那些「看起来没问题、实际埋雷」的地方。比如在协程里用了一个没做协程化的阻塞函数，整个进程就被卡住，其他协程全部排队——这种问题不会报错，只会在流量上来时表现为莫名其妙的延迟。课程会带你把这类边界一条条走一遍，而不是只讲「协程很轻量」这种结论。

配套练习要动手，光看没用

协程的知识点，看懂和写对之间隔着一整条鸿沟。建议按下面的顺序练，每个都要求你能说出「为什么这样写」：

• 用 Co\run 并发发起多个请求，对比串行和并发的耗时差，观察协程的创建开销；
• 故意在协程里写一个阻塞调用（比如 sleep），看它是否影响其他协程，再换成协程化的版本对比结果；
• 用 defer 管理资源释放，验证异常抛出时清理逻辑是否照常执行；
• 处理协程间的共享数据，先不加任何保护，看看会不会出现脏读，再补上正确做法。

这些练习不需要额外的服务器，本地起一个 Swoole 进程就能跑。跑完你会有明显的「哦，原来是这么回事」的感觉，这比背概念有用得多。

看完应该能回答的问题

拿下面几个问题自测。能答清楚，说明这门课的核心你拿到了；答不上来，回到对应章节再看一遍：

• Swoole 的协程由谁调度，和操作系统线程调度有什么本质差别？
• 一个协程在等待 MySQL 返回时，当前进程在做什么？
• 为什么协程里不能随便用普通的阻塞 IO，会出现什么现象？
• defer 的执行顺序是怎样的，它和 try/finally 的关系是什么？
• 协程环境下共享一个全局变量，可能带来什么后果，怎么规避？
• 协程数量是不是越多越好，什么情况下反而会拖慢服务？

这些问题的答案，不少在文档里也能搜到，但文档不会告诉你它们在实际项目里什么时候会咬人。这门课的价值，更多在于把这些点串成一条能用的判断链：遇到一段代码，你能快速判断它在协程环境下是安全的、还是等着出事的。

学之前先问自己一句：我现在的代码，是真在用协程，还是只是把同步代码塞进了协程的壳里？如果是后者，这门课正好补上这一段。