@shadowyue 我们公司刚开始用 electron ，后面因为性能问题，改用用 QT ，做桌面端 GUI ，完全抛弃了 js ，所以要看场景，不能绝对

@harlen 我只是个伸手党，没精力去提 mr 的

@shebaoting 那你们这个，其实可以降到 8 核试试看

线下开户很简单，没啥难度，注意一下材料，一半都问题不大

@Stevenv 也可以帮忙看看 socketio 在使用 nsq 服务的时候为什么会出现死锁问题？我们研发的水平确实只能说中规中矩，还请指教

@Stevenv 问题就在这里，在使用 resource 组件之前，其实是不知道性能拉垮的，而是在我们用了之后，过了很长一段时间，业务慢慢起来了，发现有性能问题，排查才发现是 resource 组件，但这时候所有的接口已经都用上了。

@QlanQ 也可以帮忙看看 github 上的那个死锁问题，目前困扰我们最大的就是这个了。socketio 服务使用 nsq 作为驱动，0 访问量也会出现死锁

@QlanQ 3 台机器配置怎么样？如果接口响应的数据比较复杂，有没有代码借我参考看看，怎么写会优雅一些？

@glitter1105 改造成本得全量接口都改，不如重写得了

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

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

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

@kxg3030 可以看下这个 issue： https://github.com/hyperf/hyperf/issues/7541

@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);
}
```

想请教下，我这样是哪里使用方法有问题？

@kxg3030 你们有用 resource 组件吗？目前调试发现，resource 组件需要创建大量对象，所以性能及其拉垮，暂时没想到好的办法解决

@promiser3d 日活跃用户 3000 左右，访问量不多的 50w 左右，整体算很低

@kxg3030 可以帮忙看看这两个 issue ，都是我提的关于死锁的问题，目前还是没定位原因：
https://github.com/hyperf/hyperf/issues/7517
https://github.com/hyperf/hyperf/issues/7432

看看是不是我们代码质量垃圾导致的死锁

@javalaw2010 go 有选用什么框架吗？按目前情况看，我应该也会考虑迁移，后台管理的接口就继续用 hyperf ，前台的 api 接口的话切换到 goframe 了

@shuimugan ai 写问题不大，ai 出来的主要是代码的风格不好把控，风格得以我们的习惯为主