@IMengXin 我没买了，家里找了台废弃的笔记本，换了一块固态，可以中等画质 1080p 下玩了，40-50fps 左右，不算流畅，但是也感觉不到卡，凑合了

@IMengXin 我不玩三角洲，只玩 LOL

@yulon 不至于，我 AMD1400 ，显卡 1050 ，16g 内存，4K 画质非常流畅，稳定在 100fps 上

@timelessxphw 咸鱼上找一找，应该是有的

看想要什么生活吧，人最终都会死，假设你现在 25 岁，按照 75 岁的平均年龄，大概还有 50 年的时间。如果能接受平平淡淡也是真，可以去血汗工厂拼个 3-5 年，30 岁后回去老家找个 4-5 千的工作，过平淡日子。
如果选择了这条路，就不用考虑往什么方向发展了，反正就是哪里钱多去哪里，就是卖命 5 年

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

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