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

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 超过普通的流感病毒不少

ffmpeg 虽然方便但是感觉硬件加速效果不是很好
其实也可以考虑用视频剪辑软件输出的
比如剪映。。
或者达芬奇也可以考虑下，我感觉达芬奇的加速效果似乎不错，也支持脚本

我现在只在源头校验，实现 canal 消费者的时候尽量考虑鲁棒性，单进程插入，在读取 sql ，拼装 sql ，进出队列等逻辑处都需确认成功，一旦不成功就丢入 redis 待处理队列(包括丢队列都是循环重试的不成功一直重试)并通知人工介入，这样理论上来说不会有丢失的情况只是有延迟
目前来看运行很好，因为可能出错的地方都被考虑了，只是有时候手动改了数据库结构时 canal 会失败需要人工维护下基本几个月一次
当然也可能存在意外，但我觉得这种概率很小(几年都未必能遇到一次)暂时不在考虑范围

之前研究过 可以

rdp 当然第一，各种远程都试过，目前为止没有发现任何一款能取代 rdp 的产品
备选可以用 anydesk ，老版本 anydesk 关闭更新检查端口直连体验也可以