Swoole和webman那么强，为什么laravel官方不用这些，为什么依然很多人用laravel和tp之类的

这个，强要看哪种吧。没生态只说强也没用的吧

这种东西看各种各样的需求吧，照着这个说法，go和其他语言那么强，为什么还用php？各有各的强项

主要还是很多php习惯fpm的思维模式，开发起来快，坑少。

强与弱都是相对的，swoole 和 webman 可能也有其致命的缺点。

有扩展吧 roadrunner 两个都支持

一顿操作猛如虎，一看 IP 250

laravel 和 tp 都有对 swoole 的支持，先了解了解再下结论。swoole 和 webman、laravel、tp 的区别是啥都没搞清楚呢。

现在 PHP 性能很高了！主要是 Fpm 一直停滞不前，拉胯 :joy:

因为强大的生态，开发效率，开发习惯，开发门槛，大部分项目并没有很高的并发，实现功能即可，快速上线才是王道，而且php-fpm依然是工业级的产品，如果需要效率，加机器可能比用swoole更高效，swoole和workerman只是在特定业务下才能发挥作用，但是特定业务下和go或者java有体现不出优势

因为开发快啊

你用了就知道了，fpm的方式是简单，无需考虑很多问题，如果你使用了swoole要考虑很多问题，首先变量的销毁以及内存泄漏问题，虽然swoole的性能很好，但是也要你懂它，不然你分分钟写了一堆bug

Swoole是扩展。webman是框架，webman生态和所有框架都一样，composer，开发起来并无二致。建议有重构项目，或者新项目的同学使用，特别是当你们有性能要求的时候，那是真香。没有性能要求 用啥都一样

你这问题问的， Laravel / TP 和 Swoole 就不是一个东西，前者是框架，后者是 php 扩展，再说这两个框架都有扩展支持 Swoole。

不过 Webman 确实快

先赚到钱再说，不赚钱讨论啥框架都是耍流氓

不想用

个人理解，webman虽然测试成绩很强，但是有水分的，webman的每个worker中还是阻塞执行，也就是说，涉及要访问第三方api或者某些耗时操作的话，把worker都阻塞了，性能就会大幅度下降，不像go有协程，可以挂起耗时操作先执行其他的。测试出来的性能高是因为逻辑简单，测试机器配置也好，测试时没有阻塞的情况。

Laravel和Swoole，Webman之类的框架都有各自的优缺点，并不是一个更好就把另一个淘汰。Laravel官方的选择可能是基于对Laravel框架的了解，认为它更适合满足他们的需求。此外，许多人仍然喜欢使用Laravel和TP等框架，可能是因为它们对于他们来说更加熟悉和方便，或者是因为他们已经在使用这些框架，没有必要改变。总之，选择使用哪种框架取决于个人喜好和实际需求。

都是工具 什么顺手用什么, 有的时候是性能优先, 有的时候是开发速度优先

octane 不算 laravel 官方对 swoole 的应用吗？除此之外还有 laravels 和 laravel-swoole 这些其他开发者的项目。

杀鸡为什么不用牛刀

普通的项目用不到啊，除非是高并发、长链接之类的

按照这种理论，PHP可以原地淘汰，还有就是swoole、webman这种是常驻内存的，和普通的cgi模式有比较大的差别，如果团队硬要换生态还不如直接切换语言

只谈个人看法：
你的问题是Laravel、ThinkPHP用户群更大， 使用Webman Swoole 的人不多。
回答：
laravel 官方已经支持openswoole learnku.com/docs/laravel/8.x/octan...
为何没有支持Workerman ， 你可以去搜索一下issues 已经有人提过问了。
octane 已经预留编程接口，按照实现即可。

laravel thinkphp 出现很早，已经大量积累现有项目，长期使用FPM 编程已经习惯，自然不愿意改变。
何况很多项目还没有到达性能瓶颈，他们更多关注业务如何设计。

常驻Server 优势：
Swoole 、Workerman
它们提供不仅仅是性能上提升，还有网络通信的支持。
不需要依赖第三方语言去实现。
做网络安装Gatewayworker 直接使用，定时任务直接用webman-crontab 不需要你用操作系统的计划任务。

开发效率：
webman 开发效率不比thinkphp laravel 低，常驻内存代码不更新问题，通过框架配置文件指定目录，自动代码自动更新。
掌握难度我觉得和laravel thinkphp 差不多，没有特别关注的。
只担心内存泄漏问题，这个官方有解决方案，也不必大惊小怪(go, java 都有的）

官方终极解决方案：
$worker->onMessage = function($connection, $data) {
static $request_count;
// 业务处理略
if(++$request_count > 10000) {
// 请求数达到10000后退出当前进程，主进程会自动重启一个新的进程
Worker::stopAll();
}
};

webman 生态是兼容Composer的。
官方组件 Laravel orm、symfony event、symfony console 本身大量使用第三方composer，你觉得这个说服力不够？

作者初心是简单方便很多人使用，兼容composer php 现有生态。

接下来谈谈swoole:
常驻内存无协程的swoole 和 webman（workerman） 也差不多。
但多数时候说的swoole ，指的是全协程Server。
不使用因为很多人技术能力不够，害怕解决不了问题，并且不兼容composer 生态。
单线程多协程会造成静态变量数据混乱，数据库也需要改造为连接池，那不然协程数量内存不得啃光，数据库都被并发打死。
swoole 框架主要就是hyperf，如果使用hyperf 开发只能用官方的包，如果你技术能力很强也可以自己改造composer包。
总的来说，大多数人技术不行，不敢使用，害怕翻车。

多说一点：
workerman官网webman开发: www.workerman.net/
webman admin: www.workerman.net/doc/webman-admin... 作者亲自写的
可能你担心webman 不稳定，大可放心!
webman 本身就只实现路由部分，其余全是现有comopser 生态拼装而成，不信看源码就知道。
真正决定webman 是否稳定是workerman 容器，而不是webman。
workerman 作者自己开发过很多项目，拿其中的“泡泡IM”，这个项目已经有4年多了。何况workerman 已经出现8年多了，不用怀疑稳定性。

workerman 不稳定只可能是event 扩展，但这个扩展发布很多稳定版本了。pcntl 扩展更不用多说吧！
event 稳定版链接：pecl.php.net/package/event
最早版本追溯到 2004年，不用质疑扩展稳定性。

总结：
swoole 全协程运行不兼容composer 生态，技术门槛高一些，何况很多项目未达到性能瓶颈。
webman 常驻内存多worker，兼容composer 生态环境，简单容易上手，难度和thinkphp 差不多。

等哪天, packagist 上 webman 的下载量超过 laravel 的收藏量, 再考虑用

别告诉他们webman，就让他们fpm吧，然后加机器就行，嘘，不要告诉他们，这样他们就卷不到我们了，嘘

因为webman和swoole都是cli模式，看不习惯黑洞洞的命令行窗口。直接劝退大部分初级phper

为啥看见看见命令行窗口就劝退了？现在不会命令行窗口咋开发呀

生态

php 生态大部分都是 fpm, 部分扩展包不兼容,我不想给自己找坑。

比如: octane - dact 菜单404

开发速度

cli 都要重启麻烦,开发速度会比 fpm 慢,我感觉起码增加 20% 时间。

这也是我用fpm的原因。

学习成本

想用常驻型, 可以选一门只做 cli 的语言来学。

现在的 gpt + 一堆资料 帮助下,一个月可以用新语言做项目了。

1. 因为会 laravel，tp 的，有可能不会 workerman，swoole。
2. 因为 laravel，要保证它的写法优雅。
3. 动了某些人的蛋糕。