先排查一下是不是 pmtu 问题 /t/800024

我曾经用过所谓的 passthrough 配置，就是 WAN 侧只有 /64 SLAAC RA 然后 LAN 侧用 odhcpd RA relay 模式，会有长时间无 IPv6 流量会导致默认路由丢失和同 /64 子网不互通的问题，不知道怎么修。我看你的抓包记录 ICMPv6 只有 NS 没有 RS 和 RA ，不知道会不会是类似问题。

1. 先用传统方法（ dhcp 提供的 dns 服务器）查询 doh 服务器的 ip 。这样设计的好处是自动感知纯 ipv4/ipv6 网络
2. 配置 doh 服务器时会一并配置回落 ip 地址，大部分 doh 客户端都支持这个功能

查了下 ffmpeg 文档，最通用的 mp4 容器支持 128 位密钥的 cenc-aes-ctr 加密，不过基本没 GUI 视频播放器支持解密这个。
主流的流媒体 DRM 加密都是非通用实现，没啥参考价值。
直接用 zip 打包加密就好了，注意最好用 Store 算法（就是不压缩）

2 开头的都是公网地址（ GUA ）。
通常防火墙规则是将 /64 的子网当做内网，或者根据 RA 通告的前缀长度决定，使用 SLAAC 的前缀长度不超过 /64
如果内网的路由器 RA 有广播 ULA 前缀（ fc00::/7,用途类似 ipv4 的私有地址）,也可以用这个。
链路本地地址 fe80::/10 只能在链路上用。
连不上多数自己路由器配置问题，有些路由器 WAN 侧和 LAN 侧使用相同前缀的话路由会有问题。

我从 win10 20H1 就开始不定时遇上这个问题，之后就换成 win11 insider dev 了，出现概率要低很多，也没查出原因。

@wxf666 @lslqtz 视频的话通常继续用 AAC-LC 或者 opus 就够了，带宽没紧张到那种地步。
AAC 本身有一个 HE-AAC 的版本，但仅在低码率有优势，FFmpeg 指南建议只在低于 32kbps/ch 的时候考虑使用。
aptx 和 LDAC 估计也是这个问题，不是低码率就没优势，运算更复杂，兼容性肯定打不过 AAC-LC 。

估计是预装的 windows （可能还有 office ），至少先进去一下都激活了，不然日后重装就恢复不了正版了。
出厂就有 bitlocker 的估计是支持现代待机（ S0ix/Low Power S0 Idle ）的机子，Linux 对这个的支持好像不太好，你可以看看能不能换回 S3 睡眠，也不要用太久的内核。

早期的 SM 密码体系（ SM1 ）是不公开实现+双证书体系，就是 @jeesk 的那种情况。当然不出意外地没人用。
目前公开标准化并可以在 TLS 系统中使用的是 SM2 和 SM4 ，推这玩意近 IETF 标准的好像还是蚂蚁金服的团队的功劳。
SM2 其实也就是一个自己选的椭圆曲线，跟目前常用的 NSA Suite B 一样存在参数来源不明的问题，但又没人证明这里有什么缺陷，论设计透明度都不如 Curve25519 。

这种密码算法一般就是本着自己设计的只要设计水平不落伍，就算出问题自己更有可能早一步发现而已。

音频这边的压缩改进主要不是用在网络流媒体上了，我知道这类技术用在蓝牙上还是有需求的，保持质量极限压低码率好在低带宽的 BLE 链路上传输。

@jim9606 我好像搞错了一部分，.netstandard2.0 能覆盖大部分受支持的.NET 实现，通常如果希望库在大部分.NET Framework 和所有未来.NET 版本兼容会选这个作为目标。
通常可以认为平台 Win32 API 功能最齐全，不过想要易用性我就不在行了，看有没有搞这行的大佬了。

.NET 库兼容性和可移植性上，netstandard2.0 是最佳选择，这个目标被所有 netframework 、netcore 、net5+支持。
我见过的几个需要访问 Win32 API 的.NET 应用，通常是拿到非托管 DLL （系统 DLL 或者 SDK 提取的），然后根据 C 接口用 C#自己写一个 P/Invoke wrapper 来调 DLL 的方法。这样你的主应用想用什么版本的.NET 都行。如果担心 WinUI3 没成熟的可以考虑.NET6/7+WinUI2 。
这个 wrapper 可能有现成库可以用，nuget 包通常会捆绑相应的非托管 DLL 。

事后补救可能没啥特别好的办法。
留意设置一下"微信密码"，很多人可能压根不知道这是啥，但似乎在微信风控里权重不低。

防病毒类软件试试暂时关闭？
可以试试微软出的（疑似弃坑的） ethr ，用 go 实现的可能没兼容层问题。

你如果只是想要一个针对公安系统透明但对其他实体匿名的身份认证体系，这玩意已经有了，叫 eID ，公安部牵头搞的，可以集成在银行卡上。就是。。。基本没听哪在用这套玩意。

用你打算支持的最低版本的 glibc/libstdc++/libgcc_s/GCC 组合来编译，近 10 年这三个库是向后兼容的。
通常 glibc 比较难更换，所以通常是找打算支持的最旧发行版作为基础编译环境，后两者是跟 GCC 捆绑的。
另外你可以试下用 -shared -fPIC -static-libgcc -static-libstdc++ 选项组合编译动态库，但我不清楚一个进程可不可以混用这种方式链接的库。
全套换成 musl 也可以，但你的库的上下游也只能用 musl 了，musl 缺的一些特性可能会很麻烦。

2# 的方法可以试下。

给企业用的无人值守安装是可以在系统部署时就启用 bitlocker 的。

至于为啥个人用户没提供。我觉得一方面你可以在全新安装 windows 并写入敏感数据前就启用 bitlocker ，这并不会有假删除的问题。另一方面，TPM/智能卡 /AD 网络解锁可能需要安装特定的支持软件和驱动程序，不太好预配。

另外如果你信任 SSD 厂商，可以考虑启用基于硬件加密。例如三星的 SSD 硬件加密从"准备启用"转为“启用”是需要用专用工具执行一次 Secure Erase 的，我感觉之所以有步是因为这次 Secure Erase 后实际上是已经全盘加密了。

1. 不是所有人都能安装 /更新系统 webview 的，例如某些倒霉的公司员工和 win7 用户，如果系统的 webview 有 bug 又不能更新那谁去解决？如果 webview 厂商摆烂拒不修 bug 咋解决？
2. electron 只要你不用平台的特殊特性，能提供跨平台一致的使用体验，要太难做很多软件就直接不跨平台了。
3. 就拿 Windows 最新的第一方 UI 方案 Windows APP SDK 来说吧，目前只能使用 MSIX 集中部署，而且**每个小版本的 runtime 包不共享**，在现在大概半年出一个小版本的状态，想靠集中部署省硬盘属于想想就好的状态。另外这种部署方式既不能安全清理旧版本又不能防止用户手贱卸载要用的版本。能够靠共享依赖稳定用下去的，估计只有.NET Framework 那种已经停止发展的技术吧。

@Lufs 有理由相信 Excel 出于保持兼容才对 csv 使用代码页的，谁叫 csv 没法嵌入编码标识呢。