看恐怖电影的时候播放今天是个好日子，最胆小的女孩子都敢一个人看

高度怀疑某个逻辑处阻塞或死循环了，导致无法切换上下文

提个小看法不建议为了 star 去做项目，我认为维护一个几十 star 的软钢需项目比上千 star 的通用轮子项目有意义的多
其实从这个出发点的话发起个很简单了，想想你工作或熟悉的开发领域有什么痛点、不方便的地方，然后用代码来解决 /提高效率，项目就有了

个人感觉有 2 个问题，1 是最低只需要 16 整数倍就行了，例如输入 15 字节填充到 16 即可而你的似乎会多一个 block 变成 32
另外是为了方便使用应该将 key 自动转换到 16 字节而不应该由使用者去关心具体的 key len

看到第八条，我觉得应该还不会全军覆没

https://blogs.360.net/post/%E7%94%A8-filesystem-api-%E5%AE%9E%E7%8E%B0%E6%96%87%E4%BB%B6%E4%B8%8B%E8%BD%BD%E5%99%A8.html
如果非要用 js 下载可以通过 filesystem 的方式，现在有不少新生服务都喜欢这个模式，优点是比较灵活

gorm 的 NotFoundError 这点确实很脑残，很多人都诟病，把业务错误跟服务错误都搞混了作者还坚决不改，只能自己判断下

gorm 不少地方使用起来都非常不方便，实在不明白为什么这么受人推崇 举个例子
指定字段是 Select("col1", "col2")而不是 Select("col1,col2")就非常反直觉，跟其他各种库包括数据库习惯都不一样

不过 gorm 的关联比其他库强大一点，可以灵活的实现各种关联模型

除了 gorm ，我比较推荐 xorm ，用起来也很不错

@Frankcox 你这个相当于前端把数据全部拉下来丢内存再下载 效率可想而知

大概率 fetch 的问题，前端要么直接跳转下载链接下载要么用 fs 去下载，fetch 那肯定会获取完数据才能处理，容易卡死

怎么这么多怀疑 14 岁开发的，我见过的 github 最小的开发好像是 8 岁

? Craft

这种桌椅防滑垫不行，用不了几天就掉了，然后楼上懒得贴又恢复原状，所以应该用那种套型防滑垫

阿里云的客服确实一言难尽，连他们自己的技术都要吐槽
之前数据库遇到线上事故的时候，我们急得不得了，客服悠哉悠哉的不得了

我个人感觉 google aws 的界面都还好，azure 的界面体验才是烂的不行

@dongxf 对比了下价格，确实同配置 polar 更便宜才对 最早的 rds 门槛低给了我低廉的印象

如果并发不是特别高，还可以考虑 ecs 自建
我们之前还用的更贵的 polardb ，后来线上事故阿里也不负责之后，我就迁移到 ecs 自建，再用 canal 实时同步到备份节点，成本直线降低到 1/10

doubanapi.com 这看起来可不像官方的，小心别被碰瓷了

正如你所说，因为你看到的都是带口罩的，完美做到了正确戴口罩的很少（当然也很难做到）

不过戴口罩会降低发病率这是医学界公认的，因为已知病毒致病必须满足足够病毒摄入量，再已知口罩可以降低病毒摄入量，所以为 true

但是 95%这个估计是基于以前的病毒感染估计，不能用来评估新冠，因为现在的新冠变种 r0 超过普通的流感病毒不少