Mithril

不管什么图都是 plantuml 一把梭，能直接改文本，改完渲染成图真的太香了。甚至你都能把他写到代码注释里。然后让文档工具给你渲染成图嵌到文档里。

至于什么丑不丑的压根不重要，你那个图是让人更好理解架构流程的，能理解就行。

时序图，组件图，状态图，流程图都经常画。

主要还是别被 “主流”，“经典”，“大厂也在用” 这些词糊弄住了。这些不过是方案的一些特点而已，他还有其它的优点和缺点，都要列出来调查清楚。而不是看见一个吹得好就用。

最最重要的还是要切合你们团队自己的实际情况。

比如你说的 ELK ，它的主要优点是什么，在达成这个优点的时候，需要付出怎样的搭建和维护成本。它的这些优点，对你们来说有多大提升，而成本对你们来说是不是能支付得起。

如果你们压根就不需要什么分析，dashboard ，那是不是只要个 log 定期收集汇总就行了，压根不需要数据库。
如果你们的日志量很少，那云服务厂商自己 log 解决方案给的免费额度是不是就够用了。
如果需要大量收集日志，也需要大量分析统计，那么你预计的数据量下，ELK 和 Clickhouse 都需要多少个节点，每个节点要什么样的配置？
这些节点配成的集群是不是要专人维护，维护需要的技术难度有多少？特别是故障恢复的难度有多大？
如果需要专人维护，那你们团队是不是有这样的人？或者有人对它感兴趣可以转型？没有的话，招人的难度有多大？成本有多高？

还是要从你们团队现有的资源，项目的规模，人员的情况来入手，选择适合你们的，而不是 “最流行” 或者 “最好” 的技术。尤其是当你在技术选型上有所纠结的时候，通常这个领域也没有一个能在所有方面压倒竞品的方案。

@bestkayle 信用卡跨行还款也免费。
有这两点就算它 UI 写甲骨文也有人用的。

@enchilada2020 如果我没记错的话，PowerToys 的改键是用的键盘钩子。所以你的程序如果也用了键盘钩子，可能就会覆盖掉它的，比如 mstsc 一类的。
你可以试试管理员启动 PowerToys ，或者在开了你的程序以后，再禁用然后启用 PowerToys 的 keyboard manager ，让它的钩子挂前面去。
或者直接用一些驱动级的改键，比如键盘厂自带的驱动，或者 Filco 等那些可以配置跳线的键盘。
或者试试这个：
https://github.com/cajhin/capsicain

没啥意义，特别是你这 4 块盘还都放在一起。
RAID1 的两块存重要数据，剩下直接弄俩文件夹就行。RAID0 都不用。这样就算炸了你还能剩一块盘的电影。
而且你只存电影的话，RAID1 都用不着，不如直接放网盘备份去。信不过网盘你可以买冷数据存储当备份。

@CaptainD 可以一直用你付年费时的版本，而不是年费结束时的那个。
但可以包含小版本更新，不包含中间版本。比如 2023.2.1 可以升级到 2023.2.3 ，但不能升级到 2023.3 。
即使你在年费期间可以使用 2023.3 ，但不续费的话，你只能 fallback 回付费时的 2023.2

编译用的镜像，和 runtime 镜像不要用同一个。

就你的场景而言，你可以做一个编译镜像，这个镜像的 docker file 里面拿你的依赖先 install 一下，缓存出需要的依赖，然后每次就用它编译。这个镜像大点无所谓，反正也就在你的编译机上跑。而且只在你项目依赖变化的时候才需要重新构建它，平时根本就不会动。正常情况下，你项目的依赖也不应该频繁变动。

项目本身做 multi stage ，使用编译镜像去 build ，然后产出物复制到 runtime 里做成最终的产品镜像。runtime 压根不需要什么 apt ，npm 。一个 alpine 加 node 就够了，镜像本身没有多大。

然后回到镜像管理本身，你应该有一个自己的 registry ，在你不同环境里，使用的镜像应该保持一致。就是你用来 test 的，和你扔到 production 环境里的应该是同一套东西。你 production 的不同网络，使用的也应该是相同的镜像。
通过 volume 挂载 js 是极其糟糕的做法，等同于你把二进制直接手动传到 EC2 里跑，完全失去了使用 docker 的必要性。到时候出了问题，你连对应的版本都找不到。回滚什么的更难办了。

买个保温性好的小水壶，然后饮水机接热水就行了，但大部分饮水机的水都不够热。

买个小的即热式也可以，没有加热声音，但代价就是和饮水机也一样，水不会烧开的。

茶水分离杯漏水主要是气压问题，你加完水以后先倒立几次，然后拧松放一下气，再拧紧泡就行。这样漏的水会少一些。我目前用的就是茶水分离杯，主要是茶叶在上面，你拧下来就总会有点水。先倾斜一下杯盖把水接下来就行了。