总结 Q&A：

>
但部分场景我只需要数据不被篡改, 内容可以是透明的, 但各个库都只允许对原内容的 HASH 进行加密(就是签名), 而不允许对原内容加密(库的实现就只允许使用 Public Key 加密), 这是处于什么安全方面的考虑呢

答：并不出于安全方面的考虑，而是效率和通用性

>
但我很疑惑为什么不能通过 public key 能否解密和解密后的内容来预防篡改

答： 原文是否被篡改过并不影响解密过程，在没有附带摘要（ hash ）的情况下是无法得知解密结果是否「正确」或者「能否解密」的。hash 的作用就是告诉你原文写了什么，解密后的原文 rehash 比对加密过的「真·原 hash 」一致，这才是签名防篡改的关键逻辑。你的设想是否漏掉了什么？

@vzyw

我大概能理解你的期望是什么，但很遗憾，配色是很复杂很专业的事。颜色不是静止绝对的，在不同光照条件或者说背景色下一个绝对色值完全可以呈现不同的色彩，而且相同色相、不同饱和度和亮度的颜色也可以叫成同一个名字，当你感官无法区分它们的时候，靠粗略的名字更没办法准确地辨识或选择它们。

我觉得 #13 的建议是很可取的，即使感官不能有效区分颜色，但色彩理论、配色方法这些是能通过理论学习提高的，有些从事绘画的人也色弱，他们选色就是靠的背色表。 比如 就算你分辨不出 橙色棕色绿色的区别，但你完全可以在色相环上选相近或者互补的位置，这是不需要知道这个颜色在其他人眼里看起来究竟是什么样的。

「扁鹊医术比他的哥哥们高很多」

又看了几遍 感觉你的思路有点迷

首先 liveCD 进去的这个系统，不会保留下任何配置，所以你改浅色模式这个操作有点误导。如果我没理解错此时你还在 liveCD 中，改配置是不会起作用的

然后第一次重启（就你改完不会起作用的配置之后的那个重启），理论上 installer 会修改主板的下一次引导，引导到安装好的系统上的，如果没有，那么装好的系统就还一直保留在「第一次启动前」的状态，你这时觉得重新进入了 liveCD ，我持保留意见。

然后你又重启了一次，拔掉 u 盘重启的，引导回 win 了，此时主板的下一次引导临时修改已经复原，所以回到 windows 了很正常。不清楚你第一次重启后见到的那个系统你在里头都做了些啥，不过应该不影响

再插 u 盘后的那个 detect efi bootloader 你也没理解它具体作用和效果是啥，所以你的推断也没法帮助别人做推断，此时你可以做的是引导回 liveCD 系统，把 efi 分区挂载上，然后看看它里面到底装了啥。如果真的没有装 manjaro 的引导器，那也是有可能的，有的安装选项是可选不安装引导器。这种情况下你可以用 grub-install 之类的命令（在 liveCD 里就行）手动装一下，理论上命令能正确 handle 你当前的处境。如果并不能，你还有 grub-mkimage 和 grub-mkconfig 。然后主板里自行添加你装好的 grub.efi 的位置的启动项，应该也是能引导起来的

efi 的 linux 和 win 双启动我曾经折腾了非常久，由于你的描述有点模糊所以我直接说我踩过很多坑才知道的东西：

1. 主板 flash 会存储部分引导信息，比如默认 efi 程序位置，甚至一小部分引导程序。
2. 除了 flash 里的东西，其它大部分引导程序都放在 /boot ，或者 win 叫 ESP 的那个分区里，这个分区必须是 FAT32 格式，分区里会放各个 OS 的 boot loader efi 程序，其中有一个叫 bootX64.efi ，一般主板会默认直接选择这个 efi 作为 os loader ，但它也可以不。这个 bootX64.efi 有可能装多重系统的时候相互覆盖，但也有可能安装程序会额外处理它。
3. 有些情况（比如以前装 ubuntu 的时候）下，linux 只会把 grub efi 程序放到 efi 分区里，grub 的配置文件在 ext4 分区里，当你重新 grub-install 的时候可以选择把配置文件也放到 efi 分区上，但这样做是会重新编译一个 efi 程序的，配置文件路径、当前硬盘分区 id 、搜索方式等等「内置配置」都会直接写到 efi 程序里，这个程序大概率是迁移不了的，复制粘贴到其它硬盘或分区上可能无法工作
4. 与 3 的情况类似，windows 的 loader 程序更苛刻，它的 efi 程序会把执行权交给 BCD ，bcd 又是绑定硬盘 /分区 id 的，无法用第三方工具修改也不能迁移
5. 有了以上前置知识，就不难理解 linux 的安装程序有两种处理方式：要么把默认引导盖掉，变成自己的，然后 detect 一下存不存在其它 OS ，如果有（比如 win ），那么往自己的 grub 配置里写上这一条。要么不动默认引导，只往 efi 分区里放自己的 efi 程序，然后往主板 flash 里加入新的引导配置，这样不同 OS 间可以无感共存。
6. 早年我装系统的时候，几乎都在采用第一种方式，引导顺序会被换成 grub ，然后 grub 再引导 bcd ，bcd 引导 windows 。这种顺序下，万一 linux 崩了比如你重装、删除 linux 了，那么 grub 的配置文件很可能会消失（第 3 条），留下一个空的最小功能 grub 命令行，引导回 windows 要吃一番苦头。不过现在的新安装程序好像已经大多采用第二种方式了，去主板里找 OS 列表，或者使用主板的选择 OS 功能，要比引导器套娃安全稳定得多
7. （套娃引导不再主流的方式也许与 secure boot 有关，但没深究过了）

怎么没人玩梗 甚至提到老罗的都没几个，真失望


「安静！吵到我用 TNT 写代码了！」

说了多少次 谈恋爱是两个人的是

婚姻是两个家庭的事

@LxExExl 体重 110 斤的我可以只摄入一桶薯片（ 100g ）+500ml （两盒）豆奶过一天……

我觉得我的进食多巴胺反馈根本就没建立好

你觉得能理解你描述的这个抽象概念的人类本身会理解不了这个概念造成的具体现象？

40+

这么说吧，父辈的车买来是为了做生意，我妈的驾照考下来是为了接送我上学
我的驾照是为了出门自驾游


你再想想？

我都看到 38 楼了

居然没有一个人指出 「克苏鲁」「 Cthulhu 」

而非「克鲁苏」！


这个词是一个生造词，并且在设定上「以人类的发声器官无法发出正确读音」，正因为这个小设定我还专门读了读原词的「人类发音」


讲真看到 lz 这一个词就已经觉得 应该不怎么值得期待

原则：面向接口编程
有个隐含约定即，任何一个「实现」都不应该默认理解「另外一个实现」

即使不看这个例子，我举一个抽象的：
有个 dispatch 表，满足某些条件会先进行预处理
预处理完了之后你想把数据 re-dispatch ，此时你会
* 重新调用 dispatch 的接口？
* 还是直接调用「你已经知道的那种情况的」具体流程？

--------

template <typename T, typename=std::enable_if_t<「对 T 的判断」>>
是一个经典的 SFINAE 惯用法： https://cpppatterns.com/patterns/class-template-sfinae.html
当 enable_if 的判断条件不成立，enable_if::type 就不存在，因此外面的模板 typename=enable_if<>::type 这里就不能推导出正确的类型，这个模板偏特化就会被跳过

还有一种 SFINAE 的方式是利用函数重载
https://cpppatterns.com/#/search/SFINAE

不过在今天已经基本可以用 constexpr if 取代，属于时代遗珍了