swoole社区建设意见：需要一系列稳定的PHP Lib，具备绝对领导力的framework，composer组件化

[kcloze]

很高兴看到swoole社区的繁荣壮大，swoole确实帮助开发者解决了原来不能解决的问题。 但是swoole社区文化有几个问题和想法，可以在这里跟大家分享下：

1. swoole核心是个c扩展，整个swoole-src仓库贡献者目前却总共只有68位，而php-src有536贡献者，laravel框架442位贡献者，当然直接对比这个数并不一定公平，但是能不能带动整个社区的参与度，这个指标是核心指标

2. swoole提供了很好的基础平台，号称要重新定义PHP，整个生态建立起来需要发动整个PHP社区一起贡献代码，c扩展是基础，周边应用/framework是上层建筑，前者整个PHP圈只有不到1%能贡献代码，而剩下的99%怎么参与？这层隔离是PHP自诞生以来就有的，需要想办法克服

3. swoole相关框架乱象丛生，easyswoole/swoft/SwooleDistributed/PHP-MSF/zphp/fastD/MixPHP 曾经思考过为啥这么多PHPer热衷重复造轮子呢？因为大家觉得搞个框架很容易，实现一个简单mvc就算大功告成，但是没有考虑整个生态的持续性，很多框架热了一段时间就销声匿迹，我强烈建议：swoole社区集大家之力，把一个framework做大做强，韩老大牵头，扶持和摸索一个像laravel一样有影响力的框架（PHP社区laravel/symfony/yii三足鼎立也不是好事，社区内耗严重，这也造成PHP社区没有spring cloud/Rails/express绝对有领导力的framework）

4. 目前社区很多swoole composer包都是伪composer包，为啥？因为很多依赖framework，被framework割裂的composer包是没有持续生命力的，这一点symfony做的很好，如果这个包只能在自己框架下用，只能是浪费重复劳动力

最后总结下：swoole社区要重新定义PHP，不能只关注C扩展那一部分，swoole社区真正繁荣应该用PHP Lib方式，不要再搞框架了，目前三大框架创始人最好坐一起商量，大家一起合力把其中一个框架推到PHP国际社区，到那个时候，也将是swoole社区真正繁荣之时！

[leolee2356]

i think so

[juvajuva]

很中肯,希望重视

[fupengfei058]

支持！希望重视

[jalen-qian]

支持！希望重视

[ab5272093]

支持！希望重视

[persiliao]

支持，现在的PHP圈，框架丛生，composer包的质量也是堪忧。

[wuhuabo]

i think so

[wbhniwanl]

i think so

[peng-0xff]

support！！

[Oranzh]

great idea.

[zjh129]

曾经花了很多时间用swoole framework开发一个微信接口回调处理的系统，后来要花太多时间去研究源代码，并且还要反复调试、重启服务，支持题主，希望能出一个权威的框架，方便广大开发者能参与到swoole的队伍当中来。

[PleaseCallMeXiuye]

生态很重要，统一很重要

[twose]

1. swoole-framework之前说是要实现业务代码一行不改, 一键切换为协程模式, 但是广大phper可能更需要的是一种类似babel的方式,能够将传统php应用的代码自动化转化为swoole项目.
2. 去框架的swoole-composer包, 如swoft框架虽然组件化的结构, 但是各个composer包基本都是围绕swoft框架开发, 并没有独立能力.

如果1能实现, 就和php5升级php7一样, 能够让大量的php应用无成本地迁移并且获得巨量的性能提升, 这才是phper的终极梦想.

[yeoman-chen]

支持，希望重视，希望能出统一框架

[nongmeixiaoxiong]

swoole改变了php的运行模式，但是还需要一个新的（不是旧的mvc架构）、完善的swoole的框架才能去改变phper的开发模式。

[kcloze]

已经看过不少于十个基于swoole的框架，社区方向是否走偏了？大家总是在比较谁的框架最快最易用最强大，或者就只想各占山头留个名？现在事实是没有基本的社区统一认识，虽然大家都是自愿免费提供产品，但是如果社区方向不一致，会极大分散swoole在某个领域的沉淀和突破，像之前搞出zan框架（销声匿迹了吧？），PHP做出一个framework不难的，但是基于社区文化慢慢影响PHP圈的能有多少？ PHPer如果只愿意会按照自己的思路做事情，不愿意保持开放相互借力相互精进，社区影响力只会越做越差，市场蛋糕进一步被java/golang/nods.js蚕食。

[bianyl]

支持韩聚聚牵头！

[catayi]

支持统一，造轮子太多的确容易走偏了

[fage1151]

支持,swoole社区需要很多成熟的轮子,方便更多的人加入和使用

[yannsun]

我觉得可以从改进和编写一些适合swoole运行模式的高质量的composer包开始，目前php社区内的composer包很多，但是其中有很多直接用在使用了swoole的项目内会出现内存泄漏等问题。可以参考类似这个项目https://thephpleague.com/zh-cn/

[fatrbaby]

复议

[kcloze]

社区有人在做，到一个： https://github.com/swlib 希望官方能有规划组织一个

[xmlscript]

“Swoole重新定义PHP”，不理解这句话的语境，我个人在应用层面浅薄的理解，Swoole发展特别狂野，积极吸收了其他语言新特性，极大的增强了PHP的适用范围，同时也不可避免的造成了与诸多标准的不兼容。

举个我看到的小例子，拿http_server来说，他没有工作在一个新的SAPI模式下，而是寄居在cli模式下，这造成了我的一个困扰，因为该类特立独行的提供了一些轮子（request和response类），而不是复用PHP已经形成几十年的惯例（填充到各种超全局变量和stream，如$_FILES和php://input），这就产生一个问题，过去多年积累下来的数字资产（老代码）不能方便的迁移到Swoole。

我知道用cli模式模拟一个web容器很巧妙，然而也需要帮助开发者平滑的将各种环境变量分配到各种超全局变量和stream，而不是仅仅提供一些request/response类方法，这种做法，的确很好的划分了Swoole职责的边界，但并没有把数据送到应用的嘴边，这些应用需要再封装一层多余的wrapper，就为了处理这些环境变量。

这给人留下一种完成度不高的印象。上面提到的环境变量的问题，作为应用开发者，还是能够写一层腻子wrapper来填补，然而令人沮丧的是，如果应用里使用了http_response_code()或者header()等原生方法，它们根本无法工作在cli模式下。

上述这些表面现象是我个人拙见，我也在官方文档的评论区看到有人提到类似的观点，不知道开发团队是如何计划的。谢谢。

[matyhtf]

PHP提供的php://input、$_GET、$_FILES、session_start等方法或超全局变量，仅考虑了短生命周期、同步阻塞的非并发编程。而 Swoole 定位于 长生命周期、并发编程模型。与php-fpm是完全不同的。

举一个例子，如果用 Http 服务做一个石头剪刀步游戏，三个人一起玩。php-fpm中收到其中一个人的请求，只能将结果存在额外的存储如MySQL中，每次判断是否全部提交再返回输赢的结果。因为php-fpm下，PHP代码只能看到当前的这一个请求，其他请求对PHP程序是不可见的。而Swoole下，可以同时存在3个Request对象，互相是可见的，直接处理给对应的人输出结果即可。对于Swoole这样的并发模型程序中，使用php://input究竟是哪个请求的输入内容，这个存在严重的歧义。

实际上到目前为止PHP也未能清晰地将 语言 、容器 或 框架、类库的明确界限。官方提供的标准库、超全局变量，与php-fpm/apache的东西混杂在一起。个人认为这并不是良好的编程语言设计。

Swoole重新定义PHP，我们有意地将某些不良好的PHP设计做了一定程度的改进。

在我看来，PHP语言正确的理解应当是至少分为几个层面：

语言

• 语法
• 内置函数/类
• VM
• 标准库
• 工具链

语言核心不应当包含容器、框架、类库等额外的这些内容。

容器

• php-fpm/apache，$_GET、php://input、$_FILES、session_start、http_response_code、header等这些显然应当是容器提供的功能，而不是语言提供
• swoole_http_server
• 其他容器，如workerman、reactphp 等

框架

• laravel 这样的开发框架

类库

• mysql、redis、file_get_contents、gd 等扩展
• swoole 扩展
• composer 包

[robberphex]

确实，在理想的情况下，应该是容器、框架、业务代码都有明确的接口。

但是目前在PHP这边，容器和框架的接口不是很明确，但框架和业务代码的接口现在PHP-FIG正在推进。

比如，框架将容器的请求内容（fpm或者swoole环境下）转换为PSR-7的Request对象给业务代码，业务代码也返回PSR-7的Response对象。 还有，业务代码实现PSR-15规定的Middleware接口，框架来调用。

所以，如果都按照PHP-FIG的标准来执行的话，PHP提供的php://input、$_GET、$_FILES等对于业务代码来讲，其实是已经大部分标准化了。

---

在目前的情况下，个人觉得有几件事情是swoole可以推动的：

1. 推进laravel、yii等框架官方支持swoole运行环境（自己做一个框架很难争取用户，也不是swoole的核心工作，所以推动现有框架适配swoole比较容易）
2. 由于swoole、fpm的请求生命周期都不同（比如onWorkerStart fpm就没有），所以在上一步完成之后，可以将新的生命周期模型标准化为一个PSR，推动更多框架适配

[Littlesqx]

我认为目前 Swoole 并没有吸收 PHP 已有的生态，PHP 生态中 CMS 系统，Laravel 框架等优秀的作品，Swoole 应该考虑怎么互补（Swoole 的 Api 设计有待提高，应该多遵循 PSR 规则，以及避免山寨性，比如协程语法糖 go 我觉得没有必要学 Golang，就直接 co 就好。而对于传统 PHP 生态，Swoole 的性能和异步/协程就是优势），如果得到这些开源组织的支持，相信对 Swoole 的发展很有帮助。

[twose]

前面几位可以看下 laravel-s项目 和 swoft / easyswoole 等项目和框架, 已经实现了诸位的需求, 比如swoft框架就非常专业可靠, 全部遵循PSR规范实现, 单元测试用例完善. 就swoole-src这个lib来说应该不会关注到这些框架层次的问题, 这些内容由PHP来实现会比C实现更轻松.

[Littlesqx]

@twose laravel-s 和其他类似的加速包都了解过，对传统 PHP 框架的加速都只是实现常驻内存和通过 Swoole Http Server 处理，性能提升有限，完全达不到使用 Swoole（包括 swoft / easyswoole）的性能。我的想法是 —— 怎么让 PHP 生态拥抱 Swoole 或者两者互相合作。Swoole 发展也有好几年了，相比于类似的 Node/Go，社区实在差太多。

[robberphex]

我还是觉得这两件事情有必要做：

1. 推进laravel、yii等框架官方支持swoole运行环境（自己fork一个支持的版本和官方支持差别很大的）
2. 将新的生命周期模型标准化为一个PSR，推动更多框架适配。这个是改善PHP生态的，目前PSR显然缺少很多规范

[twose]

个人认为Swoole完全丢失了PHP的易上手和快速部署优势, 本身就不适合小项目使用, 一直都是面向企业级项目, 连rango都说过swoole是面向高级PHP开发者的, 而PHPer的水平的确良莠不齐, 很多传统的PHPer完全不理解swoole的生命周期, 之前有看到数据目前PHP5到PHP7的过渡率都只有20%多, PHP使用者确实庞大, 但实际大部分用户还在拥抱PHP5...而相比之下node又有一层让前端码农低成本转向后端的优势存在, 而且node其实并不是大量用在后端, 各方面来说更加亲民, 生态好也是情理之中, 这都是很重要的原因. 而楼上几位所说的各种流行框架官方支持swoole运行环境, 大量的工作必须要有大量人力肯打输出, 我认为是非常困难的. 我倒是比较期待Swoole能作为PHP内置扩展出现在未来版本中.

[Littlesqx]

@twose 首先，每一种语言的使用者中都有所谓的低/中/高级开发者，并且每一个人都会经历低级开发者，凭什么只限定于特定的人使用而不努力推广，况且这是一个好东西啊。我们讨论的出发点都是怎么发展得更好，更多人用，而不是“这东西本来就是低级 PHPer 掌握不了的”。

我倒是比较期待Swoole能作为PHP内置扩展出现在未来版本中。

这个对于生态的发展毫无意义，只不过是减少了几行安装命令而已。如果你说的是 PHP 语言层面支持 Swoole，你先问问韩老师同意不同意。

[twose]

@Littlesqx 言重了, 我只是主观分析了一下问题的原因, 并没有其它意思. 反而我的意思更贴近"的确应该想办法降低Swoole的门槛, 但是这很困难,需要社区有人去做" 作为内置扩展是意味着被PHP社区广泛接受, 而不是减少几行命令的意义. 普通PHP程序员不要用Swoole这句话是韩老师以前说过的话...是不是玻璃心碎了一地... 我自己也是一个低级PHPer, 但我除了讨论也有在为swoole社区贡献力量, 有时候也会帮忙回答一些issue顺便提高自己的姿势, 并且从中学习成长.

也可以看看我抽空写了一半的lib, 韩老师点了star的 https://github.com/swlib 一个是0成本迁移pdo, 一个是同时支持ajax/axios/requests风格和psr风格的http-client 目前完成度很低而且没有release, 但都是试图降低swoole门槛的尝试, 也是在尝试一种低成本移植思路.

我觉得大家都是很希望Swoole能做更多事情, 而Swoole完全是韩老师和各路大牛在业余推进的开源项目, 非常不容易, 对他们来说, 他们更希望社区自己能涌现出更多的人来推动Swoole发展.

[matyhtf]

讨论了一下，我们决定在 swoole-src 中增加一个 lib 目录，在此目录中提供一个纯 php 代码实现的库。在最新版本的 swoole-src 中会自动默认加载这个 lib ，不再依赖 composer 等额外的工具。

欢迎大家向我们贡献优质的 php swoole lib ，此提案会正式定为 RFC-1009

[jasondan]

完全支持，建立官方框架这事