Swoole 下的 Hyeprf 框架，现在的维护计划怎么样？

[wh469012917]

我们的业务，是在 2020 年从 Laravel 迁移到 Hyperf 的，当时迁移的原因是 Laravel 的性能，当时是没有 Octane 组件的，迁移后确实眼前一亮。
目前 5 年多过去了，Hyeprf 虽然还在更新，但是明显能感觉到作者积极性不如以前了，github 上提的 issue ，几乎都不鸟你，能理解这种开源项目没有收入，长时间的付出没有回报，积极性下降是必然的。

所以不知道有没有人了解，hyperf 框架未来的发展计划怎么样？我们的业务是机构公益性质的，所以不存在业务倒闭的情况，目前有考虑考虑迁移到 go 语言，但是得完全重写，投入的时间精力是否值得？

[jason56]

@wh469012917 听说 swoole-cli 6.1 windows 和 macos 的兼容性会得到极大改善,团队做了大量单元测试。

[lakeme]

hyperf 该有的也都有了, 没什么需要更新的了

[pegziq]

@nicoljiang PHP 已经被 laravel 带得太坏了。
这个为什么？

[ferock]

迁移吧，别说 swoole 了，php 整体氛围都很懈怠

java 、go 都可以适合你

[elevioux]

新业务新方法。旧业务，放着咯，别出问题就行，撑不住再说。

[wh469012917]

@lakeme 倒不是功能上的问题，功能其实都能满足业务开发了，就是对未来维护上的担忧

[wh469012917]

@elevioux 我是自己的业务，不是企业里面的，所以肯定得上心

[wh469012917]

@ferock 考虑过很久，就是得完全重写，时间成本极高，第一次就是从 laravel 迁移到 hyperf ，都花了不少时间

[lxqxqxq]

机构公益性质, 独立开发者
时间成本极高 ，对未来维护上的担忧

大可不必

[codersdp1]

我们也是 20 年从 laravel 转型到 go ，现在全公司都用 go 了.

[codersdp1]

@wh469012917 #5 曾今何时，easyswoole 也是 php 之光

[wh469012917]

@lxqxqxq 就以我们目前来说，遇到的一个问题，负载一高就死锁，然后 worker 进程挂掉，master 进程主动退出，Pod 死掉，等待集群再次拉起。一直都没解掉

[javalaw2010]

渐进式迁移，当时我从 PHP 迁移到 go 的时候是这么做的，在 go 里面实现了一个反向代理，go 项目里如果路由匹配不到，就把请求代理给反向代理的后端。然后就是一个接口一个接口的慢慢迁移咯。

[canteon]

那个框架不是搞 kpi 的产物吗？这敢用

[xiuming]

@canteon swoole 搞的 kpi 产物 那有段时间一下涌现很多基于 swoole 框架 估计想打造一个爆款 现在感觉没一个爆款

[hiqxy]

公司还能撑很久的话 就转吧，不然没必要

[slowgen]

现在只是为当时的选择还债而已，5 年前就应该迁移到 go 了，再不济迁移到 nodejs 也好过继续 php 。
你现在迁移到 go 有个好处就是 AI 写 go 的能力几乎是溢出的，比其它语言准确性高很多，在 AI 加持下迁移应该很快

[Danswerme]

@shuimugan 请教下为什么说“ AI 写 go 的能力几乎是溢出的”呢？是因为 go 的开源代码非常多吗？

[kxg3030]

@canteon 没用过就不要开黄腔 我们公司 4000 个人 一直都用的全是 hyperf webman 最高并发也就 300 稳定的一匹

[kxg3030]

最早是 swoft 后来是 hyperf 都很好用 swoft 更顺手简单一些 瑕不掩瑜