标准库。

有 openapi 的就从 openapi 生成，最后还是调用标准库。

I use Arch btw

退一赔三跃跃欲试了

我是有类似的需求的，家里一台测试的笔记本，每天晚上自动 systemctl suspend （不是完全关机），每天早上我都要去按键盘去 resume ……

曾经想用 ESP32 模拟 HID 来实现，但是放弃了。

我甚至看不懂 OP 的需求

初学先用标准库，然后再用兼容标准库的“框架”，如 chi 。

你在 error 里带上调用栈也不是不行（例如 https://github.com/go-errors/errors ），然后在顶层处理，打印或者发到 sentry 。

这还是从架构角度去整吧。

有状态服务，无论如何都要处理断线重连、重启的状态迁移问题。

新启一个实例，状态迁移过去，例如发消息给客户端，让它们连到新的实例。

不用上云？也没多少 Web 框架要默认上云或强行你上云吧。

不知道为什么 Rails 8 就把 No PaaS 当作亮点宣传了。当然我是喜欢 solid 系列的包的。

挺好玩的，好奇怎样定义新的 pattern 。

Nginx 返回 504 Gateway Timeout 是因为 Nginx 自己是 Gateway/Proxy ，返回 504 让 Nginx 的客户端知道 nginx timeout 了，没有从上游获拿到响应。

除非你业务是做代理，做请求转发，不然业务逻辑故障不应该返回 504 。

@rainbowStay 不存在 “go 不推崇依赖注入” 的。

尽量统一就行，不要在深色、浅色页面来回切换，瞎眼。

我是一直用亮色主题的，浏览器也强制用浅色。

转行做套壳还是来得及的，感觉连不知道 NLP 和 word2vec 都没问题。

转行做模型，没钱没卡没数据，怕是来不及了。

把下限拉低（初学者），把上限拉高（ 3 周产出应用的独立开发者），自然能比出 10x 。

@lesismal

> 而一个 golang 进程首先是进程自己有一组(1-N 个)用户态线程, goroutine 是基于用户态线程之上的应用层语言 runtime 自己进行调度的, 最大的区别, goroutine 可不是由内核调度的。

“这组线程”就是内核线程，有对应内核调度实体，Goroutine 才是“用户态线程”。

这是非常普遍的 M:N 调度模型。M 个 Goroutine/Green thread/virtual thread/ 调度到 N 个内核调度实体上。

当然 Go 为了方便迁移 Goroutine ，还有个 P 的概念，不影响 M:N 的关系。

按照你的说法，就变成 M:N:O 三层了。