Home Sign Up Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
wh469012917
V2EX  ›  程序员

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

  •   
  •   wh469012917 · Sep 19, 2025 · 6101 views
    This topic created in 409 days ago, the information mentioned may be changed or developed.
    我们的业务，是在 2020 年从 Laravel 迁移到 Hyperf 的，当时迁移的原因是 Laravel 的性能，当时是没有 Octane 组件的，迁移后确实眼前一亮。
    目前 5 年多过去了，Hyeprf 虽然还在更新，但是明显能感觉到作者积极性不如以前了，github 上提的 issue ，几乎都不鸟你，能理解这种开源项目没有收入，长时间的付出没有回报，积极性下降是必然的。

    所以不知道有没有人了解，hyperf 框架未来的发展计划怎么样？我们的业务是机构公益性质的，所以不存在业务倒闭的情况，目前有考虑考虑迁移到 go 语言，但是得完全重写，投入的时间精力是否值得？
  • hyperf
  • laravel
  • Go
    83 replies  •  2025-09-24 20:42:16 +08:00
    justfindu
    justfindu
    Sep 19, 2025
    1
    我们也有想法想要迁移, 虽然有 Octane , 但是性能上还是差一点. 有没有什么坑需要填的
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    2
    @justfindu 你们是用的 Laravel 吗？如果是 laravel 迁移到 hyperf 不推荐，目前看 hyperf 维护很不积极，迁移到 go 倒是可以
    lait123
    lait123
    Sep 19, 2025
    3
    在用着 hyperf 后台框架 Mineadmin,感觉还行.hyperf 维护确实比较懈怠这个无解的. 但是大问题确实没有啥. 毕竟 php 热度都下降这么多了. 用爱发电的人肯定少. 生态肯定不能和 laravel 比. 转 go 考虑成本就行.

    至于其他 php 框架推荐啥的,建议直接看 https://packagist.org/ 的下载量对比就知道了.php 语言下 没有太多选择了. 现在就是 laravel tp hyperf. 至于 webman 只能说下载量摆着.

    如果你是员工 推荐转 go 给同事们多一条路子走. php 就用来搞钱吧.
    justfindu
    justfindu
    Sep 19, 2025
    4
    转 go 根本不是路子, 跨度太大, 除非新业务.
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    5
    目前维护比较懈怠是一回事，随着时间推移，未来肯定是会越来越懈怠，就怕有一天重走 easyswoole 这些老路，直接删库跑路了。对我们的业务长远来说，转 go 应该是最佳的路，但就是投入的精力问题，目前其实算是独立开发者，没有员工
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    6
    @justfindu 对我个人来说问题不大，工作上目前主要也是 go 了，php 就剩一下 hyeprf 框架在维护。如果你们用的是 laravel ，强烈不建议迁移 hyperf ，很有可能，还没迁移完，hyperf 就结束了
    liqinliqin
    liqinliqin
    PRO
    Sep 19, 2025
    7
    Swoole 正在准备一个大招 PHP AOT,让任意 PHP 代码直接生成二进制，比如 WordPress ，直接一个命令行./wordpres
    jason56
    jason56
    Sep 19, 2025
    8
    我们不用框架，直接裸 swoole 写，然后生成二进制分发
    BeforeTooLate
    BeforeTooLate
    Sep 19, 2025
    9
    所以问题在于怕没人维护跑路了，后期没法修复 bug ，性能上面我感觉不太可能瓶颈再语言上吧，大部分再 IO,数据库。
    nicoljiang
    nicoljiang
    Sep 19, 2025
    10
    @liqinliqin swoole 真是好东西，但我认为独木难支是迟早的事情。PHP 已经被 laravel 带得太坏了。
    fuchish112
    fuchish112
    Sep 19, 2025
    11
    不是计划年底发 3.2 嘛
    liqinliqin
    liqinliqin
    PRO
    Sep 19, 2025❤️1
    12
    @nicoljiang #10 我要给他再掰直，就用这个 aot
    liqinliqin
    liqinliqin
    PRO
    Sep 19, 2025
    13
    @fuchish112 #11 我给他计划改了，必须掰直
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    14
    @BeforeTooLate 性能其实问题不大，主要怕没人维护跑路，最近我提了好几个 issue ，全都没结果。甚至连是不是框架 bug 都不知道，只能自己想办法解决
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    15
    @jason56 swoole 今年，其实也只发了 2 个 bug fix 的版本
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    16
    @fuchish112 看样子是凉了
    zhumengyang
    zhumengyang
    Sep 19, 2025
    17
    年度发布 3.2
    fuchish112
    fuchish112
    Sep 19, 2025
    18
    @wh469012917 #16 那不至于，swoole6.1 预计国庆发
    Smileh
    Smileh
    Sep 19, 2025
    19
    在维护啊， 还有专门的 swoole 群 里面大佬都在
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    20
    @Smileh hyperf 维护肯定还有，但积极性大不如前了
    jason56
    jason56
    Sep 19, 2025
    21
    @wh469012917 听说 swoole-cli 6.1 windows 和 macos 的兼容性会得到极大改善,团队做了大量单元测试。
    lakeme
    lakeme
    Sep 19, 2025
    22
    hyperf 该有的也都有了, 没什么需要更新的了
    pegziq
    pegziq
    Sep 19, 2025
    23
    @nicoljiang PHP 已经被 laravel 带得太坏了。
    这个为什么？
    ferock
    ferock
    Sep 19, 2025
    24
    迁移吧，别说 swoole 了，php 整体氛围都很懈怠

    java 、go 都可以适合你
    elevioux
    elevioux
    Sep 19, 2025
    25
    新业务新方法。旧业务，放着咯，别出问题就行，撑不住再说。
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    26
    @lakeme 倒不是功能上的问题，功能其实都能满足业务开发了，就是对未来维护上的担忧
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    27
    @elevioux 我是自己的业务，不是企业里面的，所以肯定得上心
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    28
    @ferock 考虑过很久，就是得完全重写，时间成本极高，第一次就是从 laravel 迁移到 hyperf ，都花了不少时间
    lxqxqxq
    lxqxqxq
    Sep 19, 2025
    29
    机构公益性质, 独立开发者
    时间成本极高 ，对未来维护上的担忧

    大可不必
    codersdp1
    codersdp1
    Sep 19, 2025
    30
    我们也是 20 年从 laravel 转型到 go ，现在全公司都用 go 了.
    codersdp1
    codersdp1
    Sep 19, 2025
    31
    @wh469012917 #5 曾今何时，easyswoole 也是 php 之光
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    32
    @lxqxqxq 就以我们目前来说，遇到的一个问题，负载一高就死锁，然后 worker 进程挂掉，master 进程主动退出，Pod 死掉，等待集群再次拉起。一直都没解掉
    javalaw2010
    javalaw2010
    Sep 19, 2025❤️1
    33
    渐进式迁移，当时我从 PHP 迁移到 go 的时候是这么做的，在 go 里面实现了一个反向代理，go 项目里如果路由匹配不到，就把请求代理给反向代理的后端。然后就是一个接口一个接口的慢慢迁移咯。
    diudiuu
    diudiuu
    Sep 19, 2025
    34
    那个框架不是搞 kpi 的产物吗？这敢用
    xiuming
    xiuming
    Sep 19, 2025
    35
    @canteon swoole 搞的 kpi 产物 那有段时间一下涌现很多基于 swoole 框架 估计想打造一个爆款 现在感觉没一个爆款
    hiqxy
    hiqxy
    Sep 19, 2025
    36
    公司还能撑很久的话 就转吧，不然没必要
    slowgen
    slowgen
    PRO
    Sep 19, 2025
    37
    现在只是为当时的选择还债而已，5 年前就应该迁移到 go 了，再不济迁移到 nodejs 也好过继续 php 。
    你现在迁移到 go 有个好处就是 AI 写 go 的能力几乎是溢出的，比其它语言准确性高很多，在 AI 加持下迁移应该很快
    Danswerme
    Danswerme
    Sep 19, 2025
    38
    @shuimugan 请教下为什么说“ AI 写 go 的能力几乎是溢出的”呢？是因为 go 的开源代码非常多吗？
    kxg3030
    kxg3030
    Sep 19, 2025
    39
    @canteon 没用过就不要开黄腔 我们公司 4000 个人 一直都用的全是 hyperf webman 最高并发也就 300 稳定的一匹
    kxg3030
    kxg3030
    Sep 19, 2025
    40
    最早是 swoft 后来是 hyperf 都很好用 swoft 更顺手简单一些 瑕不掩瑜
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    41
    @hiqxy 我是自己的项目，不用担心项目死掉的问题，服务器都是按照 5 年起买
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    42
    @kxg3030 想问下你们 300 并发的话，机器的配置怎么样？我们是 2 台的 4 核 8G 的机器，并发稍微高一些，就大量的死锁出现，然后服务奔溃
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    43
    @shuimugan ai 写问题不大，ai 出来的主要是代码的风格不好把控，风格得以我们的习惯为主
    kxg3030
    kxg3030
    Sep 19, 2025
    44
    @wh469012917 能出现死锁 只能说代码质量堪忧 4H8G 中规中矩
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    45
    @javalaw2010 go 有选用什么框架吗？按目前情况看，我应该也会考虑迁移，后台管理的接口就继续用 hyperf ，前台的 api 接口的话切换到 goframe 了
    promiser3d
    promiser3d
    Sep 19, 2025
    46
    你们公益性质的产品，访问量如果不是特别大的话，Laravel 本身也没啥问题吧。
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    47
    @kxg3030 可以帮忙看看这两个 issue ，都是我提的关于死锁的问题，目前还是没定位原因：
    https://github.com/hyperf/hyperf/issues/7517
    https://github.com/hyperf/hyperf/issues/7432

    看看是不是我们代码质量垃圾导致的死锁
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    48
    @promiser3d 日活跃用户 3000 左右，访问量不多的 50w 左右，整体算很低
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    49
    @kxg3030 你们有用 resource 组件吗？目前调试发现，resource 组件需要创建大量对象，所以性能及其拉垮，暂时没想到好的办法解决
    kxg3030
    kxg3030
    Sep 19, 2025
    50
    @wh469012917 已经说的很清楚了 所有协程都阻塞在等待数据 阻塞了就默认是死锁 revAll 应该不会自动让出时间片 这在 go 里面也是一样的 所有协程都阻塞了不就死锁了么 这是你使用方式的问题
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    51
    @kxg3030 就以这段代码为例子，daily_sentence 、category 表总数据量低于 20 条，也会出现死锁，出现死锁的时候 mysql 和 redis 的资源利用率不超过 20%，：
    ```php
    #[GetMapping(path: '')]
    public function getSpecifyDailySentence(RequestInterface $request)
    {
    $date = $request->input('publish_at', date('Y-m-d'));
    $dailySentence = DailySentence::where('publish_at', $date)->with(['category'])->first();
    if (!$dailySentence) {
    $dailySentence = DailySentence::orderBy('publish_at', 'desc')->with(['category'])->first();
    }
    return new DailySentenceResource($dailySentence);
    }
    ```

    想请教下，我这样是哪里使用方法有问题？
    diudiuu
    diudiuu
    Sep 19, 2025
    52
    @kxg3030 对不起从来没用过，本来就是内部 kpi 产物，你用就用么。从来也没见过选型选 kpi 产物的
    kxg3030
    kxg3030
    Sep 19, 2025
    53
    @canteon 目光短浅 我都懒得跟你解释
    kxg3030
    kxg3030
    Sep 19, 2025
    54
    @wh469012917 DailySentenceResource 这啥玩意
    wh469012917
    wh469012917
    OP
    Sep 19, 2025
    55
    @kxg3030 可以看下这个 issue： https://github.com/hyperf/hyperf/issues/7541
    diudiuu
    diudiuu
    Sep 19, 2025
    56
    @kxg3030 嗯确实目光短浅
    BeautifulSoap
    BeautifulSoap
    Sep 19, 2025
    57
    PHP 的官方异步（ True Async ）已经在路上了什么时候，与其考虑转 go ，真不如再等等官方的异步。官方异步出来之后基于官方异步的网络框架肯定维护是不用担心的，swoole 这些异步可能真的会受到很大影响
    https://wiki.php.net/rfc/true_async
    maigebaoer
    maigebaoer
    Sep 19, 2025 via Android
    58
    Go 写接口远不如 PHP 爽
    youyang
    youyang
    Sep 19, 2025
    59
    @maigebaoer 是啊。。php 最好的语言。
    changz
    changz
    Sep 20, 2025 via Android
    60
    这框架用了两年了，给我坑得不要不要的，只能说算是 toy 级别的
    wh469012917
    wh469012917
    OP
    Sep 20, 2025
    61
    @maigebaoer 单纯写 API 接口，go 没有一个框架能比 laravel 来的方便快捷
    infreboot
    infreboot
    Sep 20, 2025 via iPhone
    62
    真要折腾，不如上 java ，方案是成套的。
    infreboot
    infreboot
    Sep 20, 2025 via iPhone
    63
    @wh469012917 不要用这种 resource 智障组建了，直接返回 Json 好了。直接封装一下类就行。我记得我用 laravel 的时候，最初没这种东西，都是直接返回 json ，自己封装了基础的响应体。 这估计是哪个傻插拖裤子方式的设计，我用 spring boot 3.0 都没见过这种东西。。。直接返回类的好嘛
    infreboot
    infreboot
    Sep 20, 2025 via iPhone
    64
    就这种东西响应封装组建还要弄对象池，把我整得一愣一愣的，说明框架本身就是乱设计，从来没人想过 laravel 设计 resources 的不合理性，反正它有我就的有。没见过响应并发要在代码上做对象池，一般都是他妈的上缓存啊，还要跟框架做斗争。建议直接换最成熟框架和设计 spring boot 3 。go 性能好要上也行，自己折腾吧，好多年没写
    wen20
    wen20
    Sep 20, 2025
    65
    没什么好考虑的， 一个往上走，一个往下走。 而且你担心的不维护问题，时间越久可能概率越大。
    而且，大概率熟悉 go 以后，你会逐渐放弃目前的后台技术栈。
    wh469012917
    wh469012917
    OP
    Sep 20, 2025
    66
    @Stevenv 如果简单的列表数据那其实问题不大，复杂的列表数据，会使得控制器和渲染层耦合的很厉害，会有大量的处理业务逻辑之后的数据，而这时候 resource 的作用就出来了。
    比如我一个用户列表，要对手机号脱敏、头像加签名、创建时间格式化，不用 resource 就得在控制器里面循环列表写一大堆的代码，职责不清晰。
    resource 并不智障，他是一个很好的包装器模式，但带来的就是性能及其低下，很难搞。laravel 在设计上很多都是优先考虑代码质量，其次才是性能。
    wh469012917
    wh469012917
    OP
    Sep 20, 2025
    67
    @wen20 go 写了 5 年了，整体上还是很熟悉的，切换语言整体要考虑的很多，主要是迁移上的时间成本。按目前来看 hyperf 未来不维护的概率只会越来越大，除非 php 本身能焕发新一春
    glitter1105
    glitter1105
    Sep 20, 2025
    68
    自己封装一个 Transformer 类，抛弃 Resources 。
    Dlad
    Dlad
    Sep 20, 2025
    69
    frankenphp
    caola
    caola
    Sep 20, 2025
    70
    如果是 go 的话，还还是比较喜欢用 goravel ,和 laravel 的结构很像
    wogogoing
    wogogoing
    Sep 20, 2025 via iPhone
    71
    我也是曾经的 laravel 爱好者。几年前转 go 了。

    https://github.com/keepchen/go-sail

    欢迎大佬们一起贡献❤️
    QlanQ
    QlanQ
    Sep 20, 2025
    72
    @wh469012917 #15 hyperf 在目前的 php 框架中，算是积极的了
    swoole 今年不是发了 大的版本了么现在是发了 6.0 了吧
    hyperf 现在已经是 很贴近 php 的最新版了
    考虑到 有些包不支持最新的版本，才没有急着发 3.2 的
    目前 框架整体已经很成熟了，各个方面 也都有官方对应的方案
    hyperf 整体很好用，性能也很高，前公司，日活几十万，3 台机器，就没有遇到过性能问题，倒是有一部分 切成 Java 后，服务器费用直线上升，一个 Java 微服务的服务器成本，比整个 php 项目 还高
    resource 这个东西没用过
    javalaw2010
    javalaw2010
    Sep 20, 2025
    73
    @wh469012917 #45 没有，建议自己手撸，现在有 AI ，撸个脚手架撸个组件什么的分分钟，或者习惯 laravel 的话可以试试 goravel
    wh469012917
    wh469012917
    OP
    Sep 20, 2025 via iPhone
    74
    @glitter1105 改造成本得全量接口都改，不如重写得了
    wh469012917
    wh469012917
    OP
    Sep 20, 2025 via iPhone
    75
    @QlanQ 3 台机器配置怎么样？如果接口响应的数据比较复杂，有没有代码借我参考看看，怎么写会优雅一些？
    wh469012917
    wh469012917
    OP
    Sep 20, 2025 via iPhone
    76
    @QlanQ 也可以帮忙看看 github 上的那个死锁问题，目前困扰我们最大的就是这个了。socketio 服务使用 nsq 作为驱动，0 访问量也会出现死锁
    infreboot
    infreboot
    Sep 20, 2025
    77
    @wh469012917 你所谓的代码质量，是交给一个看起来很优雅但是实际性能很拉胯的包装类。既然发现了复杂数据性能差，那为什么不自己实现 Transform 类呢, 一定要用 laravel 自带的吗？要这样的优雅干啥，不要为了优雅而优雅。既然 resource 性能有问题，那就针对部分复杂数据做 Transform ，不需要全量改代码把。简单的继续保持呗。
    wh469012917
    wh469012917
    OP
    Sep 20, 2025
    78
    @Stevenv 问题就在这里，在使用 resource 组件之前，其实是不知道性能拉垮的，而是在我们用了之后，过了很长一段时间，业务慢慢起来了，发现有性能问题，排查才发现是 resource 组件，但这时候所有的接口已经都用上了。
    wh469012917
    wh469012917
    OP
    Sep 20, 2025
    79
    @Stevenv 也可以帮忙看看 socketio 在使用 nsq 服务的时候为什么会出现死锁问题？我们研发的水平确实只能说中规中矩，还请指教
    shebaoting
    shebaoting
    Sep 22, 2025
    80
    @justfindu 我目前的充电桩平台，高峰期同时 1 万人充电。并发几百。QPS 几十。使用的 Octane 。16 核 CPU 。高峰期 CPU 的负载基本不超过 1%。

    这个性能，我觉得对于大部分中小型项目，都够了。大项目换其他语言就可以。
    wh469012917
    wh469012917
    OP
    Sep 22, 2025
    81
    @shebaoting 那你们这个，其实可以降到 8 核试试看
    harlen
    harlen
    Sep 23, 2025
    82
    @wh469012917 你改好了，往上提 mq 就有人维护了，社区项目，不能全靠作者维护啊
    wh469012917
    wh469012917
    OP
    Sep 24, 2025
    83
    @harlen 我只是个伸手党，没精力去提 mr 的
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   5424 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 106ms · UTC 02:07 · PVG 10:07 · LAX 18:07 · JFK 21:07
    ♥ Do have faith in what you're doing.