1. 项目概述从“阻塞”到“并发”的思维跃迁“PHP的协程支持”这个话题乍一听可能有点技术门槛但如果你被“Fatal error”、“Deprecated”或者“nginx php-fpm”下某个慢查询拖垮整个服务的问题困扰过那么理解协程可能就是解开你心结的那把钥匙。简单来说协程Coroutine是一种比线程更轻量的并发编程模型它允许你在一个线程内通过协作式调度的方式让多个任务交替执行从而在I/O密集型场景比如网络请求、数据库查询、文件读写中用同步的代码写法获得近似异步非阻塞的高并发性能。在PHP的漫长发展史中我们长期依赖于多进程如php-fpm或多线程如pthreads扩展模型来处理并发。这些模型在面对大量I/O等待时要么创建大量进程/线程消耗巨大资源要么因为阻塞导致CPU闲置。而协程的出现正是为了解决这个核心矛盾。它让你写的$result $db-query($sql);这样的“阻塞”代码在底层实际变成“发起请求后立即让出控制权等数据就绪后再恢复执行”的非阻塞操作。这对于构建高性能的API网关、实时通信服务、爬虫或者任何需要同时处理成千上万个慢速网络连接的场景意义非凡。当前PHP社区的协程实现主要有两大流派一是基于Swoole扩展它从底层提供了完整的协程运行时和网络编程框架二是基于generator生成器和yield关键字配合事件循环库如ReactPHP、Amp实现的用户态协程。前者性能强悍、功能全面但需要安装扩展后者纯PHP实现兼容性好但性能和功能上有一定折衷。无论你选择哪条路理解其背后的原理和适用场景都能让你在面对“高并发”、“高性能”需求时多一份从容和底气。接下来我将从设计思路、核心实现、实战踩坑到深度优化为你完整拆解PHP的协程世界。2. 协程核心原理与在PHP中的实现路径要玩转PHP协程绝不能停留在“调用几个API”的层面必须吃透其背后的运行机制。这能帮助你在遇到诡异Bug时快速定位问题是出在代码逻辑、协程调度还是I/O模型上。2.1 协程的本质可挂起与可恢复的执行单元你可以把一个协程理解为一个可以随时暂停、又能从暂停点继续执行的函数。这与普通函数“调用-执行-返回”的一次性过程截然不同。实现这个“暂停与继续”魔法的核心在PHP中就是yield关键字。当一个函数中包含yield它就变成了一个生成器函数。调用它并不会立即执行函数体而是返回一个Generator生成器对象。function simpleCoroutine() { echo Start\n; $data yield First Yield; // 在此处挂起返回First Yield echo Resumed with: $data\n; yield Second Yield; echo End\n; } $gen simpleCoroutine(); // 此时函数并未执行 echo $gen-current() . \n; // 输出Start\n First Yield $gen-send(Hello); // 向挂起点传入数据输出Resumed with: Hello\n echo $gen-current() . \n; // 输出Second Yield $gen-next(); // 继续执行输出End\n在这个例子中yield做了两件事1. 向调用者返回一个值”First Yield”2. 将函数的执行状态包括局部变量、执行位置全部冻结并挂起。后续通过Generator-send()方法不仅能唤醒协程还能将值传入作为yield表达式的结果即$data yield中的$data被赋值为”Hello”。这就是用户态协程的基石通过生成器保存和恢复执行上下文。注意很多初学者混淆yield的“返回”和“接收”。$ret yield $value;这句代码中$value是本次yield向外部返回的值而$ret是下次通过send()唤醒时从外部传入的值。这是两个方向的数据流。2.2 从生成器到协程事件循环的桥梁单个生成器只是一个可暂停的函数。要实现多个协程的并发就需要一个调度器Scheduler或事件循环Event Loop。调度器的核心职责是管理所有协程队列当一个协程因I/O而挂起yield时调度器不会傻等而是立即切换到另一个就绪的协程去执行。当被挂起的I/O操作完成时例如一个Socket有数据可读了调度器再唤醒对应的协程继续执行。以ReactPHP这样的库为例其核心就是一个用纯PHP编写的事件循环。它底层使用stream_select或ext-ev等扩展来监听大量文件描述符Socket、标准输入输出等的读写事件。你的业务代码将阻塞式I/O操作如file_get_contents替换成基于Promise或生成器的异步版本并yield出去。事件循环在背后驱动所有这些异步任务的交替执行。// 一个简化的概念性示例并非ReactPHP实际API function fetchUrl($url) { // 假设asyncGet是一个返回Generator的异步函数 $response yield asyncGet($url); return json_decode($response, true); } // 在事件循环中可以并发“同时”执行多个fetchUrl协程 $scheduler-newCoroutine(fetchUrl(http://api.a.com)); $scheduler-newCoroutine(fetchUrl(http://api.b.com)); $scheduler-run(); // 事件循环开始调度2.3 Swoole协程内核态的强力支持用户态协程基于生成器需要将每一个可能阻塞的PHP内置函数如sleep、mysqli_connect都用异步库重写一遍改造成本和性能损耗都不小。Swoole选择了另一条更彻底的路从C扩展层面直接Hook钩子PHP的底层I/O函数和网络操作。当你在Swoole协程中调用一个如Co::sleep(1)或$mysql-query()时Swoole引擎会将其底层转换为一个异步非阻塞操作并立即让出当前协程的执行权。同时Swoole内置了一个更高效的事件循环基于epoll/kqueue来监听这些异步操作何时完成。一旦完成调度器会精准地恢复对应的协程继续执行。由于这一切发生在Zend VM之下几乎无需修改业务代码的写法只需将同步客户端替换为Swoole提供的协程客户端就能获得巨大的性能提升。关键区别对比特性基于生成器的用户态协程 (如ReactPHP)基于Swoole的内核态协程安装要求纯PHP无需安装扩展需安装Swoole扩展性能相对较低存在生成器创建和切换开销极高接近Go语言协程切换在C层完成编程范式通常需要配合Promise、Async/Await语法需PHP 8.1几乎完全同步的代码风格学习成本低生态兼容需要为每个阻塞函数寻找或编写异步库提供了大量协程化的ClientRedis, MySQL, HTTP等覆盖常用场景调试难度堆栈信息可能被事件循环打断较难跟踪协程堆栈信息完整调试体验更接近同步代码实操心得对于全新的、追求极致性能的项目尤其是常驻内存的HTTP或TCP服务器Swoole是首选。而对于现有代码的渐进式改造或者在不允许安装扩展的共享主机环境基于生成器和ReactPHP/Amp的方案则提供了可行的路径。理解这个区别是你做技术选型的第一步。3. 基于Swoole的协程实战构建高性能HTTP服务理论说再多不如动手写一行。我们以Swoole为例因为它能最直观地让你感受到协程带来的“魔力”。假设我们要构建一个简单的HTTP API它需要并发查询两个不同的数据库然后合并结果返回。3.1 环境准备与基础服务搭建首先确保你的环境已安装Swoole扩展版本建议≥4.5。可以通过php --ri swoole来检查。我们创建一个最简单的HTTP服务器// server.php $http new Swoole\Http\Server(0.0.0.0, 9501); $http-on(request, function ($request, $response) { // 传统的同步阻塞写法 // $result1 queryDB1(); // 假设耗时100ms // $result2 queryDB2(); // 假设耗时150ms // $response-end(json_encode([data array_merge($result1, $result2)])); // 总耗时约250ms // 启用协程 go(function () use ($request, $response) { // 在这个go函数内你可以使用协程客户端进行并发操作 $result1 null; $result2 null; // 启动两个协程并发执行查询 go(function () use ($result1) { $result1 queryDB1Coroutine(); }); go(function () use ($result2) { $result2 queryDB2Coroutine(); }); // 等待两个协程都执行完毕 // 方法一使用Channel推荐更显式 // 方法二使用协程Defer和WaitGroupSwoole提供 // 这里演示一个简单的等待逻辑实际应用应使用WaitGroup while ($result1 null || $result2 null) { Co::sleep(0.001); // 让出CPU短暂等待 } $response-header(Content-Type, application/json); $response-end(json_encode([data array_merge($result1, $result2)])); }); }); function queryDB1Coroutine() { // 模拟一个协程化的数据库查询例如使用Swoole\Coroutine\MySQL Co::sleep(0.1); // 模拟100ms的I/O耗时 return [from db1]; } function queryDB2Coroutine() { Co::sleep(0.15); // 模拟150ms的I/O耗时 return [from db2]; } $http-start();运行php server.php你就启动了一个支持协程的HTTP服务器。使用ab或wrk进行压测你会发现即使有多个并发请求每个请求的总耗时并不会线性增长因为I/O等待期间CPU被用来处理其他请求了。3.2 使用协程客户端与连接池上面的例子用了Co::sleep模拟I/O。真实场景中你需要使用Swoole提供的协程客户端。以MySQL为例use Swoole\Coroutine\MySQL; use Swoole\Coroutine\Channel; function queryDB1Coroutine() { $mysql new MySQL(); // 注意这里每次查询都创建新连接是低效的仅作演示 $connected $mysql-connect([ host 127.0.0.1, port 3306, user root, password password, database test, ]); if (!$connected) { return [error $mysql-connect_error]; } $result $mysql-query(SELECT SLEEP(0.1), “hello from db1”); // 模拟慢查询 $mysql-close(); return $result; }但更佳实践是使用连接池。频繁创建和销毁数据库连接是巨大的性能开销。Swoole协程环境下你可以实现一个简单的连接池class MySQLPool { private $pool; private $config; public function __construct($config, $size 10) { $this-config $config; $this-pool new Channel($size); for ($i 0; $i $size; $i) { $this-put($this-createConnection()); } } private function createConnection() { $mysql new MySQL(); if ($mysql-connect($this-config)) { return $mysql; } throw new RuntimeException(Connect failed); } public function get(): MySQL { $mysql $this-pool-pop(); // 可选检查连接是否还活着ping return $mysql; } public function put(MySQL $mysql) { $this-pool-push($mysql); } public function close() { while (!$this-pool-isEmpty()) { $mysql $this-pool-pop(); $mysql-close(); } } } // 使用连接池 $pool new MySQLPool($config); go(function () use ($pool) { $mysql $pool-get(); try { $result $mysql-query(SELECT * FROM users); // 处理结果 } finally { $pool-put($mysql); // 务必放回池中 } });注意事项连接池大小不是越大越好。需要根据数据库max_connections和业务并发度调整。通常建议是(核心数 * 2) 磁盘数的一个估算值并通过压测找到最佳点。异常处理从池中取出的连接可能已断开如MySQL的wait_timeout。在get()后或执行查询前应进行ping检查如果失效则创建新连接替换。务必归还一定要在finally块或使用defer确保连接放回池中否则会导致连接泄漏池子很快被掏空。3.3 协程间的通信Channel与WaitGroup当多个协程需要协作时直接通过引用修改共享变量如上面例子中的$result1是不安全且不优雅的。Swoole提供了Channel通道和WaitGroup等原语。Channel类似于Go语言的chan是协程间安全的通信管道。$chan new Channel(1); // 创建一个容量为1的通道 go(function () use ($chan) { Co::sleep(0.1); $chan-push([data from coroutine 1]); }); go(function () use ($chan) { $result $chan-pop(); // 会阻塞直到有数据被push进来 var_dump($result); });WaitGroup用于等待一组协程全部完成。use Swoole\Coroutine\WaitGroup; $wg new WaitGroup(); $results []; go(function () use ($wg, $results) { $wg-add(); // 增加计数 go(function () use ($wg, $results) { Co::sleep(0.1); $results[] task1 done; $wg-done(); // 完成一个计数减一 }); $wg-add(); go(function () use ($wg, $results) { Co::sleep(0.15); $results[] task2 done; $wg-done(); }); $wg-wait(); // 阻塞等待直到所有add的计数都被done // 此时$results已包含两个任务的结果 var_dump($results); });使用WaitGroup可以让我们更清晰、更安全地组织并发任务避免使用while循环加sleep这种低效的等待方式。4. 用户态协程方案基于ReactPHP的异步生态如果你的环境无法安装Swoole或者你希望代码保持更好的可移植性那么基于generator和ReactPHP的方案值得深入研究。它的核心思想是“一切皆Promise”。4.1 ReactPHP核心事件循环与Promise首先安装ReactPHP核心组件composer require react/event-loop react/promise。一个最简单的例子是定时器require vendor/autoload.php; $loop React\EventLoop\Loop::get(); // 获取全局事件循环实例 $loop-addTimer(1.0, function () { // 1秒后执行 echo Timer fired!\n; }); $loop-addPeriodicTimer(0.5, function () { // 每0.5秒执行一次 echo Tick\n; }); echo Event loop starts...\n; $loop-run(); // 事件循环开始程序将在此处阻塞直到没有更多事件需要处理但这还不是协程。要写成协程风格我们需要将回调函数转换为生成器并使用一个“协程化”的函数来驱动它。ReactPHP社区通常使用clue/reactphp-block或配合awaitPHP 8.1来达到类似同步的写法但其底层依然是Promise。4.2 使用生成器包装异步操作假设我们有一个异步的HTTP客户端如react/http-client它返回一个Promise。我们可以写一个辅助函数让生成器来“等待”这个Promise完成。use React\Promise\Promise; use React\EventLoop\Loop; function asyncRequest($url): Promise { // 返回一个Promise模拟异步请求 return new Promise(function ($resolve, $reject) use ($url, $loop) { Loop::get()-addTimer(0.1, function () use ($resolve, $url) { $resolve(Response from {$url}); }); }); } function coroutine(callable $generatorFn) { $generator $generatorFn(); if (!$generator instanceof \Generator) { return \React\Promise\resolve($generator); } $promise \React\Promise\resolve(); $next function ($value) use ($generator, $next, $promise) { try { if (!$generator-valid()) { $promise \React\Promise\resolve($generator-getReturn()); return; } // $value是上一次yield表达式的返回值即外部send进来的值 // 这里我们假设yield出来的总是一个Promise $yielded $generator-current(); if ($yielded instanceof Promise) { $yielded-then( function ($val) use ($generator, $next) { // Promise成功将结果send回生成器并继续下一步 $generator-send($val); $next(null); }, function ($reason) use ($generator) { // Promise失败向生成器抛出异常 $generator-throw($reason); } ); } else { // 如果yield的不是Promise直接send回去继续 $generator-send($yielded); $next(null); } } catch (\Exception $e) { $promise \React\Promise\reject($e); } }; $next(null); return $promise; } // 使用方式 $promise coroutine(function () { echo Start request...\n; $response1 yield asyncRequest(http://api.a.com); // 挂起等待Promise echo Got: $response1\n; $response2 yield asyncRequest(http://api.b.com); echo Got: $response2\n; return [$response1, $response2]; }); $promise-then(function ($results) { var_dump($results); }); Loop::get()-run();这个coroutine函数是一个简单的协程调度器。它驱动生成器运行每当生成器yield出一个Promise时就暂停并订阅这个Promise等Promise完成后再唤醒生成器继续执行。这样从编写者的角度看代码就像是同步顺序执行的。实操心得自己写调度器有助于理解原理但在生产环境中强烈建议使用成熟的库如amphp/amp或recoil/recoil它们提供了更健壮、功能更全的协程运行时。ReactPHP生态更偏向于使用Promise和Stream的组合协程写法并非其主流。5. 协程实践中的常见“坑”与排查技巧无论是用Swoole还是用户态协程从同步思维切换到协程思维总会遇到一些意想不到的问题。下面是我在实践中总结的几个典型“坑”及其解决方案。5.1 全局变量与静态变量的污染这是协程编程中最常见也最隐蔽的问题。在传统PHP-FPM模式下每个请求独立进程全局变量互不干扰。但在常驻内存的协程环境中多个请求对应多个协程共享同一个进程内存空间。// 危险代码 class UserService { private static $currentUser; // 静态变量在进程内共享 public static function setCurrentUser($user) { self::$currentUser $user; } public static function getCurrentUser() { return self::$currentUser; } } // 请求1的协程 go(function () { UserService::setCurrentUser(Alice); Co::sleep(0.1); // 协程挂起 echo UserService::getCurrentUser(); // 期望输出 Alice }); // 请求2的协程几乎同时执行 go(function () { UserService::setCurrentUser(Bob); Co::sleep(0.05); // 比请求1先恢复 echo UserService::getCurrentUser(); // 输出 Bob });最终请求1的输出很可能变成了Bob因为请求2的协程修改了共享的静态变量。这就是协程上下文污染。解决方案避免使用全局变量和静态成员变量来存储请求级状态。使用协程上下文Coroutine Context。Swoole提供了Co::getContext()来获取一个协程唯一的上下文存储。go(function () { $ctx Co::getContext(); $ctx[user] Alice; Co::sleep(0.1); echo Co::getContext()[user]; // 仍然是 Alice不受其他协程影响 });依赖注入。将需要的状态通过函数参数或对象构造方法显式传递。5.2 阻塞操作“杀死”并发性协程的优势在于I/O等待时的自动切换。如果你在协程中执行了CPU密集型计算或一个阻塞的底层调用那么这个协程在计算期间会一直占用CPU导致事件循环被卡住其他协程无法得到调度。go(function () { $data $redis-get(key); // 协程化Redis客户端会yield没问题 $result complexCryptographicFunction($data); // 一个耗时2秒的CPU计算 // 在这2秒内整个Worker进程可能都无法处理其他请求 });排查与解决使用监控工具Swoole提供了Swoole\Coroutine::stats()可以查看当前协程数量、切换次数等。如果发现协程切换频率极低而CPU占用很高很可能存在阻塞计算。将CPU密集型任务投递到独立进程池。Swoole的Process\Pool或Runtime::enableCoroutine(SWOOLE_HOOK_ALL)后使用shell_exec会阻塞协程都不是好主意。更好的做法是使用Swoole\Process创建子进程或者利用Swoole\TableProcess实现一个简单的任务队列让专门的Worker进程去处理计算任务。主动让出在长循环中可以适时调用Co::sleep(0.001)或Swoole\Coroutine::yield()主动让出CPU给其他协程。但这只是权宜之计根本之道还是分离I/O和计算。5.3 连接泄漏与资源管理在协程中数据库连接、文件句柄、网络连接等资源的管理需要格外小心。因为协程的挂起和恢复传统的“打开-使用-关闭”模式可能因为异常或提前返回而导致资源未正确释放。go(function () use ($pool) { $mysql $pool-get(); $result $mysql-query(...); if (!$result) { return; // 错误连接没有放回池中 } // ... 处理结果 $pool-put($mysql); // 正常情况放回 });最佳实践使用try...finally确保在任何路径下资源都能被释放。$mysql $pool-get(); try { $result $mysql-query(...); // 处理 } finally { $pool-put($mysql); }使用Swoole的defer特性defer注册的回调会在协程退出无论是正常还是异常时执行类似于Go语言的defer。go(function () use ($pool) { $mysql $pool-get(); defer(function () use ($pool, $mysql) { // 注册清理函数 $pool-put($mysql); }); $result $mysql-query(...); if (!$result) { throw new Exception(Query failed); // 即使抛出异常defer也会执行 } // 处理结果 });为连接设置超时和保活网络是不稳定的。务必为协程客户端设置连接超时、读写超时并实现心跳或定期Ping机制及时清理池中的死连接。5.4 调试与日志追踪协程的并发执行使得日志输出交错传统的基于时间戳的日志很难追踪一个完整请求的链路。当出现问题时你看到的可能是一团乱麻。解决策略生成唯一的请求IDRequest ID在每个请求入口如HTTP的onRequest生成一个唯一ID如UUID并将其传递到后续的所有函数调用、协程创建中。在记录日志时都带上这个Request ID。这样可以通过grep筛选出同一个请求的所有日志。$http-on(request, function ($req, $resp) { $requestId bin2hex(random_bytes(8)); // 生成请求ID define(REQUEST_ID, $requestId); // 注意不要用define它在进程内全局唯一可用协程上下文 // 更好的方式存入协程上下文 Co::getContext()[request_id] $requestId; go(function () use ($requestId) { // 在协程内可以通过Co::getContext()[request_id]获取 $logger-info(Processing, [request_id Co::getContext()[request_id]]); }); });利用Swoole的协程回溯当程序异常或你需要调试时Swoole\Coroutine::getBackTrace()可以打印出当前协程的调用栈这对于理解协程的执行流非常有帮助。使用支持协程的调试工具Xdebug在协程环境下的表现可能不尽如人意。可以结合Swoole的Coroutine::stats()、Server-stats()以及系统工具如strace、perf来综合分析性能瓶颈和阻塞点。6. 性能优化与生产环境部署要点将协程服务投入生产除了代码正确性还需要在性能和稳定性上做足功夫。6.1 协程数量与内存控制理论上你可以创建成千上万个协程因为每个协程的栈内存很小Swoole默认约2MB可配置。但这不意味着可以无节制创建。每个协程本身有开销其内部持有的对象、等待的I/O句柄都会占用资源。优化建议设置合理的协程栈大小Swoole\Coroutine::set([stack_size 256 * 1024])对于大部分业务逻辑256KB足够可以显著降低内存占用。使用连接池限制并发连接池的大小天然限制了同时访问下游服务如MySQL、Redis的协程数量防止瞬时并发过高打垮下游。监控协程数量在Swoole Server的onWorkerStart回调中定期打印Swoole\Coroutine::stats()关注coroutine_num当前协程数。如果这个数持续异常增长可能存在协程泄漏例如某个协程永远没有结束。6.2 与Nginx的搭配部署虽然Swoole HTTP Server可以直接对外服务但在生产环境前通常还会放置Nginx作为反向代理和负载均衡器处理静态文件、SSL卸载、限流等。Nginx关键配置upstream swoole_backend { # 使用IP hash保持会话如需要或least_conn server 127.0.0.1:9501; server 127.0.0.1:9502; # ... 更多Worker进程 keepalive 32; # 启用到后端Swoole的长连接提升性能 } server { listen 80; server_name your.domain.com; location / { proxy_pass http://swoole_backend; proxy_http_version 1.1; proxy_set_header Connection ; # 清除Connection头配合keepalive proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 以下两行对Swoole Server很重要 proxy_set_header X-Forwarded-Proto $scheme; proxy_redirect off; } # 静态文件交给Nginx处理 location ~* \.(jpg|jpeg|png|gif|css|js|ico)$ { root /path/to/your/static/files; expires 30d; access_log off; } }重要提示Swoole Server需要配置正确的$request-header[‘x-forwarded-for’]来获取真实客户端IP。同时确保Nginx的keepalive超时时间与Swoole Server的keepalive_timeout相匹配或略短避免连接浪费。6.3 平滑重启与热更新对于常驻内存的服务代码更新是个挑战。直接重启服务会导致正在处理的请求中断。Swoole的热重启方案基于文件监听的自动重启Swoole Server可以配置max_wait_time和reload_async并配合Process::signal(SIGUSR1, function() use ($server) { $server-reload(); })。当向Master进程发送SIGUSR1信号时它会优雅地重启所有Worker进程。所谓“优雅”即Worker进程会等待当前正在处理的请求完成后再退出。可以结合inotify等工具监听项目文件变更自动发送重启信号。双机/多机部署这是最可靠的方式。通过负载均衡器如Nginx将流量从旧版本服务器逐渐切换到新版本服务器蓝绿部署或滚动更新。对于单机多进程也可以先启动新版本的Worker再逐步关闭旧版本。注意事项热更新无法更新onWorkerStart中已经加载到内存的类定义和全局变量。对于这部分代码的修改仍然需要完全重启服务。因此良好的设计应尽量将业务逻辑放在请求回调中减少Worker启动时的初始化负担。7. 总结与展望协程生态的现在与未来走完这一趟从原理到实战的旅程你应该能感受到PHP的协程支持绝非一个简单的语法糖而是一次编程范式的深刻变革。它让PHP从传统的“一次请求一次执行”的脚本语言蜕变为能够支撑高并发、长连接服务的强大平台。目前Swoole无疑是这个领域的领头羊其活跃的社区、丰富的协程化客户端、以及在企业中的广泛应用如百度、腾讯、虎牙等都证明了其生产级的稳定性。而基于生成器的用户态协程方案则为那些受环境所限或希望更轻量级改造的项目提供了可能性。随着PHP 8.1引入纤程Fiber作为官方扩展目前仍处于实验阶段协程在PHP语言层面的支持可能会变得更加统一和标准化。Fiber提供了更低级别的协程原语未来像Swoole、ReactPHP这样的框架可能会基于Fiber构建其上层抽象带来更好的兼容性和性能。对我个人而言在项目中引入协程最大的体会是它倒逼你写出更清晰、更模块化、资源管理更严谨的代码。因为你不得不思考全局状态、连接生命周期和异常处理。这个过程虽然开始有些痛苦但一旦适应开发出的服务在性能和资源利用率上的提升是肉眼可见的。如果你正在为PHP应用的性能瓶颈所困扰或者计划开发新的微服务、实时应用那么现在就是深入学习和应用PHP协程的最佳时机。从一个小型的内部工具开始尝试逐步积累经验你会发现一片全新的天地。