合同里有没有这种流量规定啊？请懂的人解答一下这种事情工信部管不管……

被其他语言的现代特性惯坏了之后，用 Go 有点难受，Rust 就很爽，只不过学起来真的挺难的，但也比 C++简单。

找 Rust 工作都要求有 C/C++背景，这个对于不少喜欢 Rust 的人来说是堵墙。

最新 tokio 团队发布了他们自己的 Web 框架 Axum，可以看看。

不能，从左到右一字一字对比，会出现 1.1.2>1.1.10 ，不止 JS，绝大多数语言应该都是这么设计的。

正常情况下要按分隔符“.”拆成三组，major 、minor 、patch 分别对比，高段位版本号相同才对比较低段位的版本号。

JS 有现成的 module 可以做这种对比，去 NPM 网站上搜 semver 关键字找找。

Spigot 是在 CraftBukkit 基础上进行开发的，CraftBukkit 不是一个从 0 开始做的的服务器，你可以把它看做成一个原版服务器的大型 mod，目的是为原版服务器加上 Bukkit API 。

你自己尝试构建一个 Spigot 就知道了，它会先下载原版服务器的 jar 包，然后解包，把 CraftBukkit 和 Spigot 的程序加上去，再重新打包。

Bukkit API 是对原版 API 的扩展，不修改原本的游戏内容和机制，但 plugin 开发者可以调用这些接口来对游戏内容和机制进行修改或替换。

需求是变化的，你现在的设计只能覆盖到未来有限的时间，未来的需求变化谁都没法预测，所以没必要想太远，否则就会成为过度设计。

练手做着玩的话可以先用些轻量级的数据库，比如 SQLite，后续根据运营情况来评估痛点是什么，需不需要换新的数据库方案，你用 ORM 的话一般都是支持多种关系型数据库的，迁移问题应该不会很大。

看事物要了解历史，不然你会觉得现在很多东西都很不可理喻。

我有幸接触到了近 10 年来的前端技术栈的发展变革，在我看来，Vue 如今的成功来自于：
1. 中文文档，我看 Vue 的官方文档自学，感觉文档写得特别贴心，至少我在看的过程中，萌生出来的疑问，接下来的文档都考虑到了并做了解答。
2. 宣传，创始人在各大社区做了大量的宣传，还有很多自来水也做了大量推广，在国内很多东西都是可以靠宣传拿下市场的，类似的还有 Go，宣传不力的话，东西再好可能也难以发展。
3. 特性的搭配比较符合当时开发者的普遍需求，个人感觉 Vue 是从 2.0 开始火起来的，2016 年是前端技术栈的一个重要时间点，在此之前是 AngualrJS(也就是 v1)和 Backbone 等第一代框架的天下，Angualr 后续大版本的改动很大，而且强制换了还没那么火的 TS，React 设计思路和理念也跟老框架不大相同，Vue 在保留一些老框架很常用的特性以外还引入了新的架构方案，在性能和实用性得到了提高，所以自然是在当时那个环境下比较合适的选择。
4. 国人有普遍的从众心理，大多数人选择技术栈是看别人用什么而不是看自己需要什么，是非常适合 Vue 宣传策略的土壤，从 Vue 到 Go 再到 Docker，还有 PG 、GraphQL，你都能发现这个原因的影子，东西是好东西，但我见过太多不适合还硬上的案例了。对了，题主的问题也同样有这个影子，只要本体和生态的维护工作能长期进行下去，火不火其实并不重要，技术选型最重要的是适合。

自己有折腾硬件和系统的能力的话，2000 元能搞定一台 NAS，而且性能比 4000 元的群晖好一些，群辉家用中高端系列本身就是用的 Intel J 开头的处理器，功耗 10W，华擎可以买到同系列的主板+CPU （板载焊好的），我自己之前配了一套 J4105+4G 内存+迎广 MS04 机箱（ 4 盘位），一共花了 1800，因为硬件和群晖基本是同系列所以也可以装黑群晖，但我是十几年 Linux 老用户，决定自己装 OMV 折腾，踩了不少坑，目前搞得效果不错。

网络的话看你需要，家庭内部 1000Mbit/s 还是比较容易满足的，算成字节在 100MByte/s 左右，有更高需求可以考虑万兆设备，但同时你的终端设备也得支持万兆网接口，而且也和你的硬盘速率、RAID 的速率有关。

不能折腾、不想折腾就直接买群晖，这种东西是要长期使用的，而且支出方面设备本体从来都不是大头，大头是硬盘，去搜一下 10TB 以上容量 NAS 或企业级硬盘的价格就知道了，迫于贫穷，我目前还是 4x4TB 的方案。

用实时 RAID 方案通常必须上 UPS，如果是 SnapRAID 之类的快照方案的话就不必要。

我用 XServer 的方案在 WSL 里跑 IDEA，没有任何问题。想输入中文的话需要自己在 WSL 里装 Fcitx 输入法，我没装，因为平时是纯英文开发。

https://github.com/libook/WSL-GUI#
这个是我自己写的教程。

如果是不同人用不同 IDE 、编辑器来协作开发同一项目的话，可以考虑用 EditorConfig 机制。

我就不一样，我用 IntelliJ IDEA Ultimate，我需要的所有场景都可以通过 plugin 解决。

用 git 分支可以解决。

不想用 git 可以回归 patch 方式，去搜一下用 diff 指令生成 patch 文件，然后用 patch 指令应用 patch 。

现在打击这么严，大多数诈骗电话都是从境外拨进来了，那么有一个思路就是如果自己本身没有与境外联系的必要，可以屏蔽所有境外来电。

不同运营商和手机的情况可能不一样，我讲一下我的情况。

首先我打了 10010 客服，询问境外来电的来电显示号码规则，得知境外来电号码的格式通常是：
00 国家代码 区号 号码
其中开头的“00”和“+”是等价的，所以可能是两者之一。

我是联通的号码，三星的手机，手机自带的来电拦截功能支持通配符，国内互相打电话来电显示通常不会显示 00 和国家代码那一部分，所以我配置规则屏蔽所有“00”或“+”开头的来电号码。

https://github.com/libook/WSL-GUI
这个是我自己做的教程（默认用 WSL2 ），和相关配置文件。

大体思路是：
在 Windows 上跑 XServer，可以借助 Cygwin 等方式安装 Windows 原生的 XServer ；
然后在 WSL 里，配置通过网络来用 Windows 上的 XServer 来显示 GUI，有点像远程桌面，但可以让 Windows 想对待自己的窗口一样对待 WSL GUI 程序的窗口。

如果需要用中文输入法的话得自己在 WSL 里装 Fcitx 。

有条件磨豆子的可以用磨的，没有条件可以买磨好的，或者速溶的黑咖啡。

然后喜欢甜味的话可以买甜菊糖，是一种 0 卡代糖，甜度大概是蔗糖 2 倍。

喜欢加奶的话可以考虑奶球，不过奶球每个有 100 千焦左右的热量看你是否能接受，不管是奶球还是粉状植脂末，都注意要选择正规品牌且标注不含反式脂肪酸的。

其实普通速溶咖啡主要热量在于糖，用代糖就好很多。

可以考虑用“配置中心”，有一些专门的软件和方案可以做这个。

如果跑在 VPS 里，并经常弹性增加和释放服务器的话，很多云厂商都有 VPC 的镜像功能，改配置可以打新镜像，然后用新镜像增加新的服务器，并释放旧的服务器，就完成了配置的更新，当然这个要求配置的修改可以无缝迁移。

如果你用 k8s 的话，可以用 k8s 的 secrets 方案 https://kubernetes.io/docs/concepts/configuration/secret/

上面应该已经解决题主的问题了。

建议题主去 MDN 上看一看 JavaScript 和 DOM 的相关文档，至少了解一下都有哪些功能，等写程序的时候就能想到有那么一个功能可以满足自己的需求，然后再查 MDN 文档仔细看一看就可以了。

我举个例子：

我知道 document.querySelectorAll 是个可以选取元素的方法，但我不确定它返回的是什么，就可以去 MDN 上查这个方法的文档： https://developer.mozilla.org/zh-CN/docs/Web/API/Document/querySelectorAll

看到返回值那里写的是 NodeList，但我不知道 NodeList 是什么，于是可以点击跳转到 NodeList 的文档： https://developer.mozilla.org/zh-CN/docs/Web/API/NodeList

文档里讲了 NodeList 是节点的集合，并且详细讲了如何遍历这个集合，也正好用了 querySelectorAll 来作为例子，那么我就可以遍历取出每个节点了。
此时我不清楚 Node 是啥，于是就搜 Node 的文档： https://developer.mozilla.org/zh-CN/docs/Web/API/Node

知道了 Node 是个基本类型，各种 DOM API 都是继承自 Node，父类有的属性通常子类也会有，那么可以先看看 Node 有没有 id 属性，看来没有；
那么可能 id 是 DOM API 的属性，DOM API 有很多种，文档中列举了一些 DOM API，如 Element 就是一种 DOM API，在看过了几种 DOM API 的文档之后，了解到 Document 下的对象都是 Element，那么就可以去看 Element API 的文档： https://developer.mozilla.org/zh-CN/docs/Web/API/Element

MDN 里的 API 文档主体包括三个部分，属性、方法、事件，那么咱们找的是 id 属性，所以往下拉，果然找到了 id 属性。

Redis 支持持久化，RDB 和 AOF 两种模式，一般来说 AOF 可靠一些，但即便如此，仍会有极短的时间内的数据是未持久化的，看你具体项目对丢失数据的容忍程度。

另外貌似 Intel 的傲腾貌似有 Redis 的相关方案。

其实也要看你对 Redis 的需求是什么，如果是要高速读但对写速度要求不高的话，你原有方案就可以；如果对高速写有需求的话，可能就只能堆 IO 写速率了。

Redis 还支持集群，一台机器挂了还有其他机器可以正常使用，分布式一致性策略也可以保证数据不丢失。

涉及到金钱交易我个人都倾向于有合同来保障双方的利益，否则出了问题真的只能认命。

而且捐赠和购买还是两回事，捐赠是不求回报的，购买是有权益交换的，打着捐赠的幌子来做无保障交易的话肯定就是坑了。