我个人觉得，这个更新最大的意义在于，以后在游戏群再遇到小白的“文件解压缩”提问就简单多了，只要他们问“RAR 文件怎么打开”之类的问题，只需要回他们一句“请使用最新版 Windows ，直接能打开”，不需要再手把手地教

除非是加了密的那就没办法，好在这种文件不算多

宁愿置顶旧贴都不愿意发新帖，还拒绝过别人提漏洞，OP 这种自己拆自己台的行为实在怪怪的

有两个地方：
C:\Users\<user>\AppData\Local\Postman
C:\Users\<user>\AppData\Roaming\Postman

Postman 的内容都保存至这里，可以试试进去看看有没有自己的原先的记录

如果找到了，复制这两个文件夹到其它地方暂存，然后降级到旧版 Postman ，再还原上述两个文件夹，或许有用

我个人更推荐老城区的景色，尤其是越秀区和荔湾区的。

沿江路就有许多，像是粤海关博物馆、沙面建筑群，附近还有石室圣心大教堂，是个文物。

广州乃至广东的特色建筑，不是什么高大上的新建筑，而是“骑楼”，就是楼主在步行街看到的那种建筑，建筑物楼下有一排排的支撑柱，柱外是马路，柱内侧的人行道刚好位于建筑物底下，由建筑物帮路人遮风挡雨，很适合暴晒+突然大雨的岭南地区。

在老广的眼里来看，有“骑楼”的老城区才是真正的广州。

刚才提到的“石室圣心大教堂”，它所在的那条路也有连片的“骑楼”。

如果楼主有时间，还可以逛逛“荔枝湾”，现在这里也是景点。

还有文明路，这里有许多粤式甜品。
文明路的西侧（与文德路交界）有个卖“钵仔糕”的小店铺，用料比街头摊档更足，口感更好。
然后在文明路的中段，位于德政路的交界处，有多家甜品店，人气很旺，十分火爆，品种很丰富。

关于吃的，还可以前往西华路，这里也是美食一条街，东段尤其多。

最后不能不提一个稍为冷门但又贴近热门地方的好去处——二沙岛。
海心沙（广州塔的所在地）的那条桥（海心桥），另一头连接的地方正是二沙岛。这个岛的居民非富即贵，所以环境十分安静，适合静下心来看风景。暂时性的美中不足是，岛中央正在修地铁，会有些许噪音。
二沙岛上还有星海音乐厅，音响效果比天河区的广州大剧院好得多。音乐厅最近几天都有演出，如果楼主有音乐爱好，也可以找一场试一试。

如果楼主时间比较多，可以参观下中山纪念堂，顺便路过附近的建筑。旁边有省府大楼；纪念堂正门对面是市府大楼（这也是文物建筑），再往南是人民公园。逛到这里就能理解为什么两府都不愿迁到天河区，因为市中心能有相对清静+ 高绿化率 + 交通方便的地方实在不多。
如果再继续走，公园南侧正是“公园前”地铁站商圈，附近就是北京路步行街，应该就是楼主逛过的地方。

刚需 docker 的话，要么 Windows + docker in WSL ，要么直接纯 Linux

不听，甚至戴上降噪耳机把降噪等级调到最强

需要安静环境集中注意力

非自建一样可以被叫去喝茶，认定要不要去喝茶的决定权又不在用户手上

像是 express vpn 、nordvpn 这些，他们的宣传广告向来主要是“隐藏 IP 、保护隐私”，非墙国家的用户才是他们的主要服务对象，比如不想网站知道自己的 IP 地址（连接 VPN 后，出口 IP 就不是自家的），在用户连接了公共 WiFi 后再透过 VPN 上网（不信任公共 WiFi ，而 VPN 有加密可以保护这段过程传输的数据），这才是原本的服务场景。

至于爬墙，那还是用专门的梯子技术吧。

根本原因在于长期不开源。

当下流行的 Top 10 编程语言，全都是开源的。无论榜单标准是 TIOBE ，还是 IEEE Spectrum ，或是直接看 GitHub 的语言排名，全都不例外。

C# 最初也不开源，但最终开源了。Delphi 呢？至今仍然闭源吧。第三方的 Delphi 开源兼容品，地位不就类似于 C# 未开源时的 mono 嘛。
C# 闭源时，mono 都没法推动 C# 火起来。更不用说至今仍在闭源的 Delphi 了。

@cnbatch 手误，“贝尔电话公司早就被拆散了”应为“AT&T 公司早就被拆散了”

@holy_sin C 以及 C++连“官方”编译器都没有，更别说官方包管理器了

其实很长时间以来，包管理是由操作系统自己的软件包管理器负责的，系统的软件包管理器同时就是 C/C++的包管理器。这原本是很方便的优势。
只不过 Linux 发行版特别多，无法保证想用的包全都能出现在所有发行版当中。
再加上 Windows 和 macOS 完全不做这种事，想要管理那就只能靠第三方软件（例如 vcpkg ，尽管也是微软的，但并不是预装在 Windows 当中）。
于是，优势成了劣势。

难怪不少语言索性自带包管理工具。

如果 C 以及 C++背靠大公司，那么或许还能有个集大全的包管理器。可惜现实并不能。当初诞生 C 以及 C++的贝尔电话公司早就被拆散了，ISO 委员会也没资源去干这样的事。
真想要做，那就必须两个 ISO 委员会（ C 语言的 9899 和 C++的 14882 ）同时协调着做，难度就更高了（时间会浪费在官僚式扯皮当中）。

FreeBSD 的驱动问题应该能修好的，就看 FreeBSD 开发组什么时候能够拿到硬件实物做测试

我自己的 NAS 同样是基于 FreeBSD 的（衍生版，附带 WebUI ，为了方便出门在外时用手机远程检查状态），机箱内所有硬盘都是 ZFS ，系统盘也不例外

同样为了防止 bit rotate ，不但有 ECC 内存（这才是关键），并且不使用 SLOG 和 L2ARC 。慢就慢吧，不管再怎么慢，顺序读取都有三四百 MB/s 。
只要机械硬盘是 raidz 组的一部份，那就基本不用怕翻转错误，raidz 可以纠错的。独立单硬盘的出错才麻烦。专门给二级缓存再加 SSD raid1 有点奢侈，我小机箱放不下那么多╮(╯-╰)╭

是不是开着远程桌面？

我曾经遇到过同样的现象，后来排查发现原来是“远程桌面”导致的

（以下描述带有我个人的使用习惯，请谨慎参考）

包管理：

Windows 用 vcpkg
FreeBSD 用系统自带管理器
Linux 尽量用系统自带管理器，实在没办法了才用 vcpkg


C++版本：

部份版本变化还是很大的，按分组来算（以下是我个人划分），那就是
第一组 C++98 、C++03
第二组 C++11/14/17
第三组 C++20/23
每一组内部的变化不算特别大，很容易平滑升级；组与组之间的变化比较大，可以当成新语言来学习


跨平台：

只要不是涉及到驱动层面、调用系统专属 API 的话，大多数纯命令行工具的跨平台不算痛苦，因为有不少第三方库包装得比较好，把平台差异抹平了

图形界面程序比较麻烦，主要是因为 Linux 割裂但又不完全割裂。如果不考虑 Linux ，只考虑 Windows 、BSD ，那就会轻松很多。Windows 不用多说，可以直接静态编译出单个 exe 到处用。BSD 也类似，静态编译出来后，同系列上下游都能用。同系列上下游是指 FreeBSD → GhostBSD 这种上下游衍生关系，不是 FreeBSD→NetBSD 这种的跨系列。
（此处只针对单纯的 GUI 界面程序，不涉及游戏 3D 绘图）

还有其它选择，比如 XFS 和 BTRFS
不过 BTRFS 没 ZFS 那么稳定就是了，也许只剩 XFS 可选

我在公司里会用 C++写命令行工具（哪怕是 Windows Only 的），这时候就可以放飞自我了，因为不用开源，我想怎么写就怎么写，甚至写出一大堆不符合 C++ Core Guidelines 的代码。反正这时候的目标只有一个：能跑不崩就行。

@cnbatch 顺便再补充个我是怎样迁就 BSD 的

首先，有个很重要的一点，BSD 全系列全部自带 C/C++编译器，我很喜欢这一特点。哪怕是 FreeBSD 的衍生版本，即使是变成了防火墙系统（比如 OPNSense ），依然都自带编译器。
其次，我发布的二进制文件未必涵盖 BSD 系统自己支持的硬件平台，但我希望其他人在这些平台里，可以顺利用自带编译器编译我的代码。这样就不需要额外安装其它语言的编译器了。
那么能用的语言就只有两种：要么 C ，要么 C++。
再结合我先前提到的，“想用到方便的语言特性”，只能选 C++。

语言选好了，接下来选标准。
到目前为止，FreeBSD 仍在受支持的最低版本是 12.x ，其中 12.0 自带的编译器是 LLVM 6.0, 最高能支持到 C++17 。直到 2022 年更新的 12.4 才升级到 13.0 ，可以稍微支持 C++20 。
所以当下这段时间我会继续使用 C++17 。等到 FreeBSD 12.x 停止支持了（今年年末），我再升级语言标准也不迟。

@Cu635 这里就有：
https://doc.rust-lang.org/nightly/rustc/platform-support.html
Tier 3 当中就有提到，RISC-V FreeBSD 并不支持，但 RISC-V Linux 却又是 Tier 2 支持，显然对 BSD 的支持并算不完善。
而 BSD 系统自己支持的平台比这个列表要多，虽然我个人并不可能每个支持的平台都编译一次二进制文件，但如果有人刚好有 BSD 支持的偏门硬件（而 Rust 不支持）又刚好想拿来编译一下，那么他就没办法做到编译了。

我并不喜欢给 BSD 使用者设限，因为我自己就是 BSD 使用者，尽管我跟对方所使用的 BSD 未必是同一种类。

我也更偏向用 C++，尤其是个人项目。

Windows Only 的项目除外，这时候我会根据实际需求选择 C# 或者 C++，不会定死只用一种。

个人项目跨平台时，我只能选 C++，因为我跨的平台相对“偏门”。不但有 Windows 和 Linux ，还有整个 BSD 系列——FreeBSD, NetBSD, OpenBSD, DragonflyBSD 这几种。
毕竟我既想用到方便的语言特性，又想二进制文件尽量小，不要“拖泥带水”挂靠 VM ，还要兼容 DragonflyBSD （尽管没什么人用，但我还是会给它编译出二进制文件）。这样下来可选范围非常窄，对我来说也就 C++最适合了。

自己手动转换基本上不可能，等于重新造一个 ICU (International Components for Unicode)，不如直接调库吧