Swoole的协程支持意味着即使您正在执行大量昂贵的I/O（例如，与数据库对话、使用文件系统、发出HTTP请求），您也可以处理许多请求。Bootstrap只加载一次，因此您不必为每个请求支付15%到25%的税。因为这是初始化的一部分，这意味着您在每个请求上使用更少的资源，包括RAM和CPU。对于某些应用程序，这可能意味着您需要更少的服务器，这可能已经归因于异步运行时。不需要另外的web服务器说到更少的服务器，你不需要web服务器，因为Swoole是一个web服务器。你可以启动一个只安装PHP的Docker容器，你不需要在它前面安装NGINX。您不必在同一个容器中编写NGINX或Apache，它可以只是PHP。而且，如果您打算进行任何类型的容器化，那么使用一种语言的那些单进程容器确实是黄金标准。更高的请求上限有趣的是，ZendFramework和Laminas社区的成员认为异步服务器可以处理的请求数量是标准设置的四到七倍。当然，您可以将Apache和NGINX调整得非常快，但是使用异步服务器可以变得更快，Node一次又一次地证明了这一点。缺点虽然上面列出的好处可以为PHP应用程序带来可观的好处，但Swoole仍然有一些明显的缺点。这些缺点可能包括：代码重新加载调试每个事件一个侦听器SwooleResponse的“end()”方法非标准请求/响应API，用于查看更改的影响。不幸的是，Swoole中缺少重新加载代码的功能。那是因为它是一个长期运行的过程。因此在刷新时它使用与更改前相同的代码。Swoole中有一些热代码重新加载功能，但目前无法重新加载引导实际服务器实例（想想应用程序实例、DI容器、配置）本身所需的任何东西。调试可能是一个挑战，因为Swoole的协程支持与Xdebug和Xhprof不兼容。您将需要习惯日志记录。响应“结束”方法在Swoole中，如果忘记调用“$response->end()”，连接将保持打开状态，直到发生网络超时。这意味着当前进程保持打开状态，这意味着事件循环不再存在。最终，这将导致超时，您将获得超时，但超时仍然是一个问题。所以如果你能从中抽象出来，你就可以避免头痛。（需要此函数，以便Swoole知道响应何时完成，并可以释放worker来处理另一个请求；但是，从用户的角度来看，这是有问题的，因为很容易忘记调用它。）因此，这是一个非常Swoole运行时中有用且方便的功能，但如果您可以在自己的代码中避免它会更好。https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...非标准请求/响应API"$response->end()"方法是Swoole中非标准请求/响应API的一个例子。它不遵循PSR-7规范（PHP的HTTP消息接口），甚至不遵循任何框架实现，例如Symfony的HTTPKernel或laminas-http。因此，如果您直接编写Swoole，但仍想使用自己的框架，则需要进行调整-但这可能是个问题。
