虽然说可以通过键盘重映射实现，但我觉得脑子受不了。
敏感信息输入还是考虑用密码管理器吧，基于软件或者基于硬件的都行。

我一般只改设置 APP 里面的那个，文件关联就等用到再设置，反正也不怎么常用。
不过文件关联这波负优化从 win10 首发版本就有了，win11 只是维持现状而已。

@lifansama 桌面版也不用的，一般都会装个手动启动或者自动停止的提权服务，Edge 、Chrome 、Firefox 、Steam 都会这种操作。

一般将缩写当普通单词比较普适，也就是 HttpClient 。
考虑在 golang 里的命名规范，首字母大小写区分公私有成员，私有成员 httpClient ，公有成员 HttpClient ，如果全大写就会搞出 hTTPClient 这样不伦不类的命名。

B 后缀就是 BGA 封装的 Desktop 处理器，虽然 Apple 有用但应该不是特供，真特供的连 ARK 都查不到。
9 代和 10 代都是 8 代 Coffee Lake 马甲，除了频率高一点，几乎无差，没做特殊 SKU 算是意料之中。
讲道理我觉得 Apple 没什么理由看得上 11 代，你要说 12 代我觉得都合理些。

就算 ffmpeg 可以用 http range ，不代表它能得到合适的时间轴信息啊。指定视频流时间范围下载需要特殊的 Web 服务器扩展。也没有什么靠谱的方法避免 GOP 被切割下载。
求稳还是全部下载下来再转换吧。

我不信 HTTPS 也能精准，几乎所有用了 TLS 的应用层协议都长一个样。

估计是只做版本更新不做安全更新了。Server 2019 这种 LTSC 分支估计不是很要命的漏洞就不去动的。
还好微软还没干出像 Apple 那样要自家用户去找上游 curl 作者要支持的蠢事。

@cev2
感谢详细解答了。
看得出 Google 为了节省安装体积还是花了很多心思设计的。

不过我感觉大部分 APP 厂商（不分国内外，包括部分 Google 产品）都只将心思放在 APK 体积（或者下载体积，考虑传输层压缩和二进制差分）优化，而忽视了安装体积。这些行为包括：只分发 armeabi 原生库，压缩原生库（安装时需要解压，占用额外空间,甚至用了 App Bundles 还这么干），将资源和可执行代码推迟到运行时下载（然后忘记清理旧版本）。

Android 拒绝支持 Stateful DHCPv6 还算有积极作用的。
我能猜到，有些网络设备商为了偷懒，仅仅将 DHCPv4 换成 Stateful DHCPv6 就宣称 IPv6 Ready 了，因为这两个运行模式是完全一样的，这样可以偷懒不做完善的组播功能（ SLAAC DAD 依赖）也不用支持多地址主机了。而且 Stateful DHCPv6 的实现方式也很容易暴露网络拓扑和导致主机 ID 被跟踪。日后如果需要多地址的应用，会少很多阻力。举个可能的例子，为了避免利用地址跟踪用户，同设备上不同的 APP 分配使用不同地址，Stateful DHCPv6 的服务器实现很有可能拒绝分配多个地址。
至于 Stateless DHCPv6 ，现阶段好像就一个通报 DNS 服务器而已，这功能用 RA 就能解决了。另一个用途是通告 Captive Portal ，RFC7710 ，也是同理。

如果你有捡垃圾的爱好，这些东西会被大船企业级 SSD 和万兆网卡占据。

@cev2
com.android 开头的包就是系统厂商自行维护的，不能由 Google 更新是设计要求。
就算 AOSP Webview 不能更新，也可以自行安装 Google Webview+Trichrome Library 吧，这玩意又不需要特许权限。在开发者选项可以改 Webview 实现，应该能满足需求吧？

不过我知道国内 APP 通常引用腾讯 TBS 或者阿里系那样自带 UC 内核，感觉都不用系统 Webview 的。

顺带吐槽一个我至今不明白 Google 为啥要将 TrichromeLibrary 和 Webview 拆开，前者没法在系统设置里看到和卸载，我听说有些系统因为部署流程有问题 TrichromeLibrary 更新会残留删不掉。

没有年份版本号的 Windows Server 跟桌面 Windows 用的是相同的 WaaS 发布模型，两个版本的 Release 都是同步发的，半年或一年一个版本。
有年份版本的 Windows Server 对应桌面桌面 Windows LTSC ，例如 Windows Server 2019 对应 Windows 10 1809 LTSC （ 17763 ）

5950X 最强 MSDT 编译用 CPU ，嫌贵就 5900X 。

除非 Windows 大版本更新，否则 Windows 正常启动流程不会主动修改 UEFI NVRAM 引导选项。
有些品牌的 BIOS 会主动检测 Windows Boot Manager 是否存在并主动添加，例如 Acer Insyde 和 Intel VisualBIOS 就有这种行为。有些 BIOS 会有影子 NVRAM 导致 efibootmgr 、bootice 等工具的修改无效，Acer 就有这种设计。

如果只是用特定规则进行一对一变换，那不是很有意义。
有意义的用法，例如利用 PNG 透明背景在正常图片中隐藏信息，或者将二进制 payload 嵌入一张正常图像并可以抵抗主流互联网平台的缩放和压缩失真。

其实只有 glibc 会恶心人，因为许可证不允许这玩意静态链接非 GPL/LGPL 程序。
musl 倒是没这问题，但很多项目没法用这个。

@Meano @elfive @Soar360
目前感觉比较省事的方法是在接口类初始化时通过 SetDllDirectory ，这样 extern 方法只要写一个。
但我现在不了解的情况是 Windows on ARM 的实际运作情况。AnyCPU （非 Prefer32bit ）在这个 OS 上是运行在 64 位 CLR 上的吗？这时可以加载 x86 DLL 吗（通过 xtajit 翻译为 ARM64 ）? 如果是 Win11 ARM ，是不是还可以加载 x64 DLL （通过 ARM64EC 翻译为 ARM64 ）? 如果在 Environment.Is64BitProcess 为 true 就选择 x64 DLL 目录，会出问题吗？

Dev 的设置可以选更多固定。
不过非常推荐用 Windows 搜索或者 PowerToys Run 搜索取代开始菜单找应用，Win11 的搜索已经不像 Win10 那么愚蠢了，纯键盘打个首字母通常都能找到。