你要知道在 2013 年那会儿，多数分析都认为 NFC 打不过二维码，因为 NFC 要求特定硬件，二维码的缺陷是至少一方需要联机，而那时中低端机基本上都是阉割 NFC 的，而且小米 3 开始数字系列就取消了 NFC ，知道大家追随 Apple Pay 搞虚拟卡支付才把这个硬件加回来。

我觉得现在二维码能进地铁公交也不是什么纯效率导向而是多方利益斗争的结果，公交本无力推动手机 NFC 普及，但 Apple 把这事情解决了。另外，公交希望另起炉灶踢开卡公司，银联放弃电子现金转向免密联机账户支付，4G 网络完善，都是促进二维码进公交的重要动力。

NFC 的既得利益者也是很顽固的，就说跟健康码联动这事，公交卡也完全可以做到的，但卡公司压根没去推动这个事。

对于大部分低频需求用户而言，好用=可以白嫖服务器。
如果不是因为这个，Windows 下最好用的就是 RDP 。

到手就关掉水印打开地理位置。

@tulongtou 正经人谁会用 Windows Console Host 啊，要么用套壳第三方 mintty 或者 Windows Terminal ，要么就上 WSL1/WSL2 了。

USB-IF 规范的 USB-PD 兼容线缆没有支持 6A 的，最高只有 5A 。
有些是增加触点，例如早期 oppo 的 VOOC ，但只能做线头一体来保证安全性。
现在多数是私有拓展，线还是用 5A （按 PD 要求会嵌入一个 emarker 小芯片，但私有协议可能会往里面塞额外标记）的，设备和充电头通过握手判断可不可以超规格使用。
我建议直接当这些私有协议不存在，只看 PD （顶多加个 QC ）能到的功率，PD 规范都支持 PPS 了有啥非得用私有协议不可的，都是想圈钱。

@LxnChan 那还不错，可惜我用的 MI9 没得升了，我也不想升。不知道有没有改默认行为的方法。

我觉得只有 Apple 和 Web 开发会喜欢用 MAC 吧，前者还是因为没得选，后者我就不知道啥原因了。我是不相信 MAC 更适合开发这个说法的。
反正现在 M1 在纯 CPU 的非 ASIC 应用上没什么根本性优势。

之前早有讨论了，WiFi MAC 探针，这个使用随机 MAC 对抗是铺开得比较早的事了。
针对主动连接的 WiFi 进行随机化的主要障碍是破坏了某些企业受控网络对持久化 MAC 地址的假设。企业网络可能要更换接入认证手段。 @littlewing 所说的问题也是其中一种，不过这种非便携设备直接用静态 IP 配置也够了。
不清楚 Apple 允不允许用户针对特定接入点停用随机化。MIUI 是可以主动选择的，可惜默认值是使用持久 MAC 。

dhclient ，dhcpcd 是独立 DHCP 客户端，负责根据 DHCP 服务器的指令维护接口的 IP 地址、DNS 等东西，用户不会直接接触，之所以依赖这个是因为它的功能比较全。
wpa_supplicant 是 WPA 无线安全支持服务，同样用户不会直接接触。目前有替代者 iwd （ wpa_supplicant+dhcpd 的集成品，还加了些功能）。
iw ，iwconfig 是手动管理 WLAN 接口用的，不是 debug 用户不会直接接触。
net-tools(ifupdown,/etc/network)已淘汰（十几年没更新了），但在一些没有下面这几个东西的发行版里只能用这个。

systemd(systemd-networkd,systemd-resolved)、GNOME NetworkManager 、WICD 是用户接触的一站式网络配置程序，你只要知道这个咋配置就够了。

我建议 GUI 系统统一用 NetworkManager ，非 GUI 系统统一用 systemd-networkd ，这样上面只剩一个 wpa_supplicant 可能要留了。

因为不是所有应用层 /传输层协议都在 packet 中包含域名信息（例如 TLS 的 SNI extension 和 HTTP 的 Host 头）。

所以如果要完美的话，需要劫持 DNS （遇上 DoT 、DoH 、enforce DNSSEC 、私家 HTTPDNS 还是没辙），将所有域名查询与一个保留地址池（例如 E 类 IPv4 关联）并作为 DNS 响应返回，然后根据关联 IP 进行路由。

如果你把支持的协议做一下限定，会简单不少。

补充一下：
上面说的压缩图片选项在全系 Office 软件中都有，可以如法炮制。
另外 PowerPoint 中画的形状可以选中后右键另存为图片，这里可以选择 svg 且是真正的可以无损缩放的矢量图。相比起直接 ctrl+c/v 的好处是可以用在非 Office 环境，缺点是没法编辑。

如果图是用 PowerPoint 画的，直接 ctrl+c/v 复制过去 Word 就行，不要截图。
Word 会模糊是因为保存时会压缩图片。在文件-选项-图像大小和质量，对“所有新文档”选择“不压缩文件中的图像”，默认分辨率选择“高保真”。
另外如果真要截图，用系统自带的 PrtSc 或 Win+Shift+S ，不要用什么 QQ 微信，经常给你压到 96ppi 根本看不清。

洗个牙就这么痛苦估计牙龈问题不小。
我这边私营牙科单纯洁治+抛光就 150 左右，你这个花费估计还要算上牙周上药了。
陈年老石该洗还是要洗，不然以后就是牙龈炎（刮治是其中一个治疗手段）和牙槽骨退化。

对于只读或进行原地修改的数组参数的 func ，使用 slice 可以免去需要传三个参数(*arr,pos,len)的麻烦。
golang 中 array 的长度是类型的一部分，对于希望接收不定长函数的 func ，只能用 slice 。

@duke807
我说的完备可不是引用成熟的 AES 实现那么简单。密码原语基本都不是弱点。
PIN 要通过 salt 和 KDF 函数转换成 AES 使用的主密钥来提高暴力破解难度；需要认证（ AEAD ）来防篡改；流密码模式的 IV 怎么产生；主密钥多久替换一次；怎么做 padding ，如果明文片段可以被猜测，能不能抵抗选择明文攻击。

当然对于个人用途，这些都不做可能不是什么问题。

@424778940
我没说错。
我说需要 TPM （ TPM Protector ）的是操作系统驱动器的**自动解锁**，使用 recovery password （ Numerical Password Protector ）解锁的不属于自动解锁。本来恢复代码就是最高安全性的方法，增加其他 protector 都只是为了省去每次解锁都要输恢复代码的麻烦而已。恢复代码本身需要比 PIN 更严格的保密措施。企业环境可以仅创建唯一的 AD Protector ，避免员工拆硬盘在非域控主机上解锁驱动器盗取数据。

不可能在不掌握 recovery password 又不通过其他 protector 解锁的情况下，使用 Numerical Password Protector 解锁驱动器并获得 recovery password （这都是废话了）。如果楼主自己不知道 recovery password ，除非想办法恢复送修前的 PCR 使得 TPM Protector 可用，无法解锁。

如果通过组策略选择使用 TPM+PIN 联合，系统会创建另一个 TPM&PIN Protector 并删除 TPM Protector ，正如你所说的，两者是完全不同、相互独立的 protector 。接受 PIN 输入的不是 TPM 固件而是引导器 BOOTMGR （所以一定需要 Secure Boot 避免被篡改的 BOOTMGR 实现邪恶女仆攻击）。

@duke807
不是说 cryptsetup 不行，是用这个东西为基础做 Windows 那套基于 TPM 的无密码自动解锁太麻烦了，这套东西凑齐 SecureBoot(MOKManager)+shim+grub2+LUKS+TPM ，还要不能把内核更新、DKMS 模块搞崩。我都没心情实战操作一次。如果无所谓每次输 PIN 的话那确实够了。

且不说你这个轮子实现是不是完备吧（造密码学轮子极易犯错），“可否认性”是不符合的，“文件没有特征”也是特征，防不住五美刀扳手( https://xkcd.com/538/ )。 你还是得藏得够好没被搜出来。但你要是自信能藏好，那不加密也没事。

看你装在哪，自行安装一般放在 /usr/local 下面，默认的 ld.so.conf 里， /usr/local/lib 优先于 /usr/lib 。
你可以用 ldd 检查加载了哪个版本。
听不懂我在说啥的就先卸载自编译的版本。