这框架用了两年了，给我坑得不要不要的，只能说算是 toy 级别的

@maigebaoer 单纯写 API 接口，go 没有一个框架能比 laravel 来的方便快捷

真要折腾，不如上 java ，方案是成套的。

@wh469012917 不要用这种 resource 智障组建了，直接返回 Json 好了。直接封装一下类就行。我记得我用 laravel 的时候，最初没这种东西，都是直接返回 json ，自己封装了基础的响应体。 这估计是哪个傻插拖裤子方式的设计，我用 spring boot 3.0 都没见过这种东西。。。直接返回类的好嘛

就这种东西响应封装组建还要弄对象池，把我整得一愣一愣的，说明框架本身就是乱设计，从来没人想过 laravel 设计 resources 的不合理性，反正它有我就的有。没见过响应并发要在代码上做对象池，一般都是他妈的上缓存啊，还要跟框架做斗争。建议直接换最成熟框架和设计 spring boot 3 。go 性能好要上也行，自己折腾吧，好多年没写

没什么好考虑的， 一个往上走，一个往下走。 而且你担心的不维护问题，时间越久可能概率越大。 而且，大概率熟悉 go 以后，你会逐渐放弃目前的后台技术栈。

@Stevenv 如果简单的列表数据那其实问题不大，复杂的列表数据，会使得控制器和渲染层耦合的很厉害，会有大量的处理业务逻辑之后的数据，而这时候 resource 的作用就出来了。 比如我一个用户列表，要对手机号脱敏、头像加签名、创建时间格式化，不用 resource 就得在控制器里面循环列表写一大堆的代码，职责不清晰。 resource 并不智障，他是一个很好的包装器模式，但带来的就是性能及其低下，很难搞。laravel 在设计上很多都是优先考虑代码质量，其次才是性能。

@wen20 go 写了 5 年了，整体上还是很熟悉的，切换语言整体要考虑的很多，主要是迁移上的时间成本。按目前来看 hyperf 未来不维护的概率只会越来越大，除非 php 本身能焕发新一春

自己封装一个 Transformer 类，抛弃 Resources 。

frankenphp