非必须。

我个人坚决不用、不学 VIM 的任何“新”功能（指的是原版 vi 不具备的那些功能），反正各个 IDE 自己的默认模式也没多碍事

这显然不是“字体渲染”的问题，是“字体使用”的问题。正如前面楼层所言，是 CJK 字体回落的缘故。

这几套字体，不仅大小不同，连文字粗细都不同，甚至字形规范都不同，不管怎么渲染都无法改变这三点。
要是真有渲染技术能把不同粗细的字体都渲染成相同的粗细，不同的大小都渲染成相同大小，甚至渲染成统一字形规范，谁敢用啊😑

所以可以看看软件设置选项里面是否可以自己调整字体。
最根本的做法是反馈给软件开发商，告诉他们做好字体的选取与使用。

要不然的话，那就只能把 CJK 每个语言区的默认字体文件替换成同一种了。

不如期待下 2038 ，看看到时候哪些设备会崩掉

那就真不应该用 WPS 了，如果要用，也该扔进虚拟机
国产毒瘤值得享受“扔进虚拟机”的待遇

简单的 PIN 很多，右侧小键盘区，竖着输入就行了。

比如

7410258

8520147

或者斜着输入

753159

951357

画个图来表示的话：

https://i.imgur.com/yKgjthq.png

1password 管理开机密码？这种做法太奇怪了吧，至少灵活性很糟糕

最直接的办法，自己写个程序调用系统 API：
https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-idesktopwallpaper-setwallpaper

写成 exe 和 vbs 都可以，不过最好还是 exe ，因为微软自己说了 vbs 会被淘汰，万一哪天移除 vbs 支持那就没法用了

我也有个类似的跨平台工具，纯实验性质：
https://github.com/cnbatch/PunchNAT
本机测试连接是有效的，OP 可以对比下哪里不同。

由于不清楚 rust 怎么写，所以只能描述我自己的做法。

我的做法很简单，监听的时候，不设置任何 interface ，表示监听全部接口。
然后设置 IPV6_V6ONLY 为 false ，表示使用 IPv6 栈接管 IPv4 ，此时会用到 IPv4-mapped IPv6 。
当然了，可以手动切换为纯 IPv4 模式。

目前可以确定一件事，微软的远程桌面比较容易吞剪贴板内容，其中 UWP 最容易出现这种事（然而窗口化时它的 DPI 匹配效果比 mstsc 好多了，选择困难）

那就绕个圈：
首先，自己写 exe ，或者几个脚本，实现目标就是双击后可以切换到对应桌面
第二步，这几个 exe 或脚本，固定到任务栏
第三步，可以使用常规的 Win+数字键调用对应图标，快速切换

可以左手按键盘右侧的 CTRL + WIN + 方向键

由于没提到设备型号，只能靠猜测。可能与硬件 NAT 加速有关系。
乱按之前，硬件加速莫名失效，变成软件 NAT ，受限于 CPU 不够强，导致网速不佳；乱按之后 NAT 设置顺便被重置，恢复了硬件 NAT 加速，于是网速恢复正常。

我把我的 traceroute 结果贴出来，方便 OP 使用。如果 OP 确实要找电信的话。

traceroute6 to 240e:3b0:26a:c0e1:adf3:d16d:dbbf:eb06 (240e:3b0:26a:c0e1:adf3:d16d:dbbf:eb06) from 240e:3b2:690:xxxx:xxxx:xxxx:xxxx:74c5, 64 hops max, 28 byte packets
　 1 　 240e:3b2:690:xxxx:xxxx:xxxx:xxxx:xxxx 1.041 ms 1.699 ms 1.122 ms
　 2 　 240e:3b0:619:: 3.554 ms 3.637 ms 5.907 ms
　 3 　 240e:1e:0:2a63::2 4.575 ms
　　　 240e:1e:0:2a69::2 3.399 ms
　　　 240e:1e:0:2a65::2 3.628 ms
　 4 　 240e:1e:0:3994::3 2.851 ms 2.924 ms
　　　 240e:1e:0:3996::3 2.752 ms
　 5 　 240e:3b0:26a:c0e1:adf3:d16d:dbbf:eb06 4.575 ms 3.629 ms 4.059 ms

traceroute6 to 240E:3B0:200:969D:6DBE:AB99:7E08:3 (240e:3b0:200:969d:6dbe:ab99:7e08:3) from 240e:3b2:690:xxxx:xxxx:xxxx:xxxx:xxxx, 64 hops max, 28 byte packets
　 1 240e:3b2:690:xxxx:xxxx:xxxx:xxxx:xxxx 1.003 ms 0.874 ms 0.847 ms
　 2 240e:3b0:619:: 5.396 ms 3.796 ms 5.574 ms
　 3 240e:1e:0:2a63::2 3.136 ms
　　 240e:1e:0:2a6b::2 5.772 ms
　　 240e:1e:0:2a6d::2 3.100 ms
　 4 　 240e:1e:0:19d5::3 14.365 ms
　　 240e:1e:0:19d0::3 2.486 ms
　　 240e:1e:0:19d7::3 19.167 ms
　 5 　 240e:3b0:200:969d:6dbe:ab99:7e08:3 4.098 ms 5.611 ms 3.386 ms


traceroute6 to 240e:3b0:26a:c0e1:adf3:d16d:dbbf:eb06 (240e:3b0:26a:c0e1:adf3:d16d:dbbf:eb06) from 240e:3b4:c8:xxxx:xxxx:xxxx:xxxx:xxxx, 64 hops max, 28 byte packets
　 1 　 240e:3b4:c8:xxxx:xxxx:xxxx:xxxx:xxxx 1.065 ms 0.243 ms 0.227 ms
　 2 　 240e:1e::1470 16.764 ms 2.417 ms 1.848 ms
　 3 　 240e:1e:0:19e9::2 4.838 ms
　　 240e:1e:0:19e0::2 3.648 ms
　　 240e:1e:0:19e5::2 7.941 ms
　 4 　 240e:1e:0:3997::3 2.784 ms
　　 240e:1e:0:3995::3 2.651 ms
　　 240e:1e:0:3996::3 2.933 ms
　 5 　 240e:3b0:26a:c0e1:adf3:d16d:dbbf:eb06 4.123 ms 3.449 ms 3.488 ms

traceroute6 to 240E:3B0:200:969D:6DBE:AB99:7E08:3 (240e:3b0:200:969d:6dbe:ab99:7e08:3) from 240e:3b4:c8:xxxx:xxxx:xxxx:xxxx:xxxx, 64 hops max, 28 byte packets
　 1 　 240e:3b4:c8:xxxx:xxxx:xxxx:xxxx:xxxx 0.268 ms 0.208 ms 0.174 ms
　 2 　 240e:1e::1470 2.229 ms 1.675 ms 20.093 ms
　 3 　 240e:1e:0:19e9::2 3.709 ms
　　 240e:1e:0:19e8::2 2.680 ms *
　 4 　 240e:1e:0:19d0::3 2.398 ms
　　 240e:1e:0:19d6::3 2.677 ms
　　 240e:1e:0:19d1::3 2.822 ms
　 5 　 240e:3b0:200:969d:6dbe:ab99:7e08:3 3.307 ms 2.997 ms 2.484 ms

这两个地址，我用广州电信的两条宽带（不同区）都能够 ping 通

而且我这两条宽带相互之间都能 ping 通、互联。对了，ipw.cn 的广州节点似乎有问题，它未能完成 ping 我宽带的 IPv6 ，直接显示 PingFailed

不过我没试过同区家宽互 ping （没理由敲邻居家门借网测试吧），不清楚是不是越秀区的特例，不妨再找电信的人来检测下，顺便把这次测试结果给他们看

这就是为什么我坚持在电脑保存一份原始认证码，以及更倾向于搞一套硬件密码器（我还发过提问贴），就算做云端备份也要保留一份手动备份。毕竟完全依赖手机的话，不但一点都不可靠，而且一个意外就能搞得自己手足无措。我就经历过。

只不过有一大堆人迷之自信，觉得“意想不到的状况”一定轮不到自己，认为我的提问不合理，把我狂喷一顿。Naïve!

不如试试 trace route 看下是在哪里开始断掉
然后顺便搞个 tcping 以及 iperf ，看看能不能通

不一定是在注册表启动，StartUp 文件夹也可以做同样的事情
两个位置：
%appdata%\Microsoft\Windows\Start Menu\Programs\Startup
%ProgramData%\Microsoft\Windows\Start Menu\Programs\StartUp

Firefox 的视频解码曾经有 bug ，播放视频时会显存泄露
https://www.reddit.com/r/firefox/comments/bz8z2p/firefox_using_all_of_my_gpu_memory/
https://bugzilla.mozilla.org/show_bug.cgi?id=1702927

我自己就遇到过这个 bug ，GTX 显卡的显存被它占了两 G 多，关掉浏览器后就迅速恢复原状

我猜 Firefox 可能怕再次出 bug ，改成了默认不使用硬解吧