这个问题问得特别戳中CPU设计的核心权衡点——其实类似的思路不是没人想过，但主流CPU最终还是选择了分支预测而非双分支并行，根源在于成本、复杂度和实际收益的巨大鸿沟，咱们掰开了说：

• 硬件资源直接“爆炸”
  要同时执行两个分支，CPU得同时维护两套完全独立的执行上下文：寄存器快照、指令重排序窗口、执行单元的分配……现代CPU的ALU、浮点单元、缓存本来就已经是寸土寸金的芯片资源，要是直接翻倍甚至多倍配置，芯片面积、功耗会飙升到不可接受的程度——不管是移动端的续航，还是服务器的散热成本，都扛不住这种开销。更别说内存带宽了，同时预取两个分支的指令和数据，会直接把缓存总线堵死，反而拖慢整体性能。

• 分支路径会指数级“发散”
  很多分支不是孤立的，后面往往跟着嵌套分支。要是每个分支都并行执行两条路径，那执行路径会像指数一样膨胀：3层嵌套分支就有8条路径要维护，5层就是32条——CPU根本不可能支撑这么大规模的并行上下文，很快就会陷入资源耗尽的困境。

• 错误分支的回滚成本极高
  就算你硬扛着资源消耗跑了两个分支，最终还是要确定哪条是正确的。现代CPU是乱序执行的，错误分支的指令可能已经修改了缓存，甚至发起了内存写入操作——要把这些副作用全部回滚，复杂度远超分支预测失败后的简单清空指令窗口。相比之下，分支预测错了只需要丢弃未提交的执行结果、重新取指，成本低太多了。

• 收益的边际递减太严重
  其实现在的超标量CPU已经在做基于分支预测的单路径推测执行，而且分支预测的准确率已经高达90%以上（甚至很多场景能到99%）。为了那1%的错误场景，去付出翻倍的硬件成本，性价比低到离谱。只有在极少数分支完全不可预测的极端场景下，双分支执行才可能有收益，但这种情况占比极低，不值得为它重构整个CPU架构。

至于你提到的“编译器预先加载两个分支”，其实编译器确实会做类似优化：比如用__builtin_expect给CPU提示分支倾向，或者把简单分支转化为条件移动（彻底消除分支），再或者循环展开减少分支次数。但这是编译期的静态优化，和硬件层面的runtime双分支并行完全是两回事——前者成本低、针对性强，后者则是牵一发而动全身的架构级改动。

说白了，分支预测方案用相对低的成本，拿到了几乎最优的执行效率，这才是它成为主流的核心原因。

内容的提问来源于stack exchange，提问作者AbstractDissonance