V2ex Polish 还不错的，我目前正在使用。主要自带的美化主题蛮讨喜的。

@mohumohu 感谢建议，过段时间忙完回家了，我来研究下这个。🥰

Unraid 可以，存储安全性也可以，就是写入速度折半。如果想要满速（单盘）写入，可以开 Turbo Write 。但是此模式下就不能休眠磁盘了。

哦对，Unraid 有时候会碰到一些坑，可能需要你有一定的 Linux 运维知识才能处理。

PPSS. Unraid 默认 Cache Pool 用的 Btrfs ，强烈建议换 zfs （目前官方支持在 RC ，六月应该可以正式发行）。

半个月前刚炸了个用 btrfs raid0 的缓存池——而且我恢复不了。原因 metadata 写满了，然后不知道什么情况（可能是 btrfs 没做啥处理），直接存储系统 corrupt ，变成只读模式了。尝试了 Linux Kernel 给出的修复意见，无效。
最后自己迁移了数据，损失了 300g+ 的数据。

大概率网络问题，换个节点就好了。

系统天气 和 天气通 App 混着用。相对来说 天气通的天气数据精确度比较 ok 的，而且提供的数据丰富度和开了 Pro 的彩云天气一样。

盒子模型问题，强烈建议任何项目开始前导入个 normalize.css 来完成所有浏览器 CSS 的标准样式重置。
content-box 的坑很大，强烈建议使用 border-box 。

@a632079 更正一下，UploadHandler 应该替换为 UserHandler 来着。UploadHandler 会因为有 io 等待而自动推到 microtask 队列里（等待轮询 io 状态改为完成后，继续执行），然后释放执行句柄，直接恢复到中间件上下文继续执行——因此中间件被返回了，此时直接开始依次返回，最终返回结果。

@a632079 更正一下，使用 nextTick 一般是用于优化执行逻辑的。上段文字少了这句注解。

@lingo9 后面解释了：因为 JS 运行时的单进程单线程机制，调用一个函数如果没有需要 io 等待的话，会立即执行完这个方法——因此在此种情况下你那个方法的逻辑等价于 中间件任务 -->UploadHandler --> Handler 返回 --> 中间件返回。这也是为啥很多情况下我们会通过 nextTick 这个操作来手动将任务放到微任务队列最顶端。

可以补充个例子来帮助你理解：为啥 forEach 和 for 的行为表现类似？都是执行完这个代码块后直接执行后面的步骤。

如果还是不理解的话，可以直接简记为（虽然不是绝对的，但是完全这样是没错的）：Koa 中任何方法都为 async 方法即可.

P.S 如果直接在函数里面错误使用 Async 方法闭包的话（可以直接转换为同步函数），配置好的 ESLINT 应该会给出 error 或 warning 提醒，并给出修复意见来着。

不是，老问题了，国行 ROM 的 API 地址被修改到了 cn 。换成非国行的 ROM ，或者三方 ROM 可以彻底解决整个问题。
目前打开代理的情况下，cn 域名也会解析到国际版的解析服务（忘记是通过 301 ，还是直接分区域解析的了）

改成 async function 后加了 next() 前加了个 await 是吧。

出现这个疑问是因为，LZ ，没有深刻认识到基于 async 方法的 Koa 洋葱模型 以及 Node.js/JavaScript 异步的处理机制。

以下为分析过程。

简单版：Koa 是洋葱模型，next 是一个 Promise<T> 的函数，如果不等待的话，按照 JS 正常的执行逻辑就直接返回了，此时 Promise 虽然还在执行，但是由于 Response 已经被发回，就算修改了，也体现不到你的客户端响应里。


至于为啥就 upload 接口会出现这个问题，可以参考 Node.JS 的数据竞争问题。
分析：这里有个大前提：Node.js 的 JS Runtime 是单线程单进程，io 任务是基于 libuv 的多线程微任务。由于 Upload 有一个 Stream 处理的过程，这个是一个异步 io 等待任务，一般会安排到下一次 eventloop 进行状态检查，而 由于大前提，此时自然而然的就把函数返回了，然后将 Response 发回。当进行 n 次 eventloop 后，发现上传的 io 处理完了——但就算再怎么修改状态也没用了。
同样的，其他接口为什么正确也很好理解了，由于单线程单进程，此时没有 io 等待，这个微任务立马开始处理，response 成功被修改，然后在是中间件返回，整个堆栈依次 pop 然后返回消息。

看上去比官方的工具完善多了！非常感谢，已 ✨ 收藏。

@chuck1in 如果下一代还是掌机且没有独显的话（类似 SteamDeck 的），掌机模式能 1080P60HZ ，底座模式能 1440P30Hz 感觉就灰常棒乐。
——所以现在体验的最好方式居然是模拟器，呜呜呜？

作为丁克族，我觉得除了留下的必要的防冲资金（比如说留个 20w ？），剩下的该爽就爽吧。爽不掉的就继续存着。目前的经济形式对于普通人来说非常不利啊，再不乐，说不定以后都没得乐乐。

😱 楼主就当恰个教训吧。所以国内推广 NAT 还是比较合适的，大部分人对网络安全这块都不太懂。

楼主如果愿意麻烦一些的话，而且没有共享服务给别人使用的需求的话，不妨试试 VLAN 的方案。比如说 Zerotier 、TailScale （ HeadScale ）这类的。

我平时在外面带着一个 R4SE 软路由，OP 上挂着 Zerotier 。家里的网是中移的，NAT1 ，平时核心软路由挂着 Zerotier 和 自建的 headscale （方便手机访问）。

在宿舍的时候，访问家里的任何设备就和在家一样，随意操作，带宽也是能跑满上传 100M 的。
在外面使用移动数据访问的时候比较麻烦，我是常开圈 X 的，如果需要操作内网设备需要打开 TailScale App ，终止圈 X 的服务。**我觉得这算是最麻烦的地方了**。

如果是安卓设备的话，应该是可以 Root 后跑个常驻后台的 tailscale-cli ，达到不用关 VPN 就能访问内网的目的。

这个其实是 Clash 设计的问题，它默认认为 DNS 是可信的，所以按照一般的配置是这样的，优先使用 114 DNS 请求 IP （除非直接碰到了 filter 设定的域名，这会直接转交给 fallback DNS ），如果这个 IP 符合一定规则，再使用 fallback DNS 再请求一次。

**这通常是有效的。**
但是当遇到运营商墙中墙，比如江苏屏蔽了 mypikpak （直接把 DNS 的 A 记录污染到国内 IP ，这种情况不会 fallback ），亦或者新的 GFW Domains （直接返回本地 IP 、国内 IP ）。这种策略会出一些问题。

为了解决这个问题，我在软路由同机器跑的 ArchLinux 起了个基于 Mosdns 4 的 easymosdns 来解决这个问题——这个方案也不太完美，内置的域名列表，IP 段太少了，导致很多域名和 Passwall 一样，直接拿到了境外站的 IP ，比如说 ipip.net 。但目前算是好用的解决方案了。

@xuanyuanaosheng #27 这个是 2.9.2 的了，不过可以结合 #2 获取到 2.9.1 的 commit