Solidity^0.8.0下使用SafeMath反而更省gas？这合理吗？

这种情况是完全合理的，核心原因和编译器优化、检查逻辑的实现差异以及测试场景有关，具体拆解如下：

• 编译器优化的差异
  Solidity 0.8.x内置的溢出/下溢检查是通过在字节码中自动插入CHECKEDADD/CHECKEDSUB等专用opcode实现的，而SafeMath是用纯Solidity代码编写的检查逻辑（比如require(a + b >= a, "Overflow")）。部分编译器版本或优化配置下，会对SafeMath的代码做更高效的内联和逻辑合并，反而比自动插入的内置检查生成更紧凑的字节码，减少gas开销。

• 正常执行路径的开销差异
  在不会触发溢出的场景中，SafeMath的检查是一个简单的算术比较操作，而内置的CHECKED* opcode虽然语义上等价，但实际执行时的底层开销可能略高于Solidity层面的比较判断。只有在溢出触发异常的场景下，两者的revert开销才基本一致。如果你的测试用例都是正常路径，就会出现SafeMath更省gas的结果。

• 编译器版本与优化选项的影响
  早期的0.8.x版本（比如0.8.0-0.8.5）对内置检查的实现还不够成熟，字节码生成效率不如手动实现的SafeMath。另外，不同的优化等级（比如optimizer runs参数设置）也会影响代码生成：如果你的优化配置偏向于“少运行次数下的高效代码”，SafeMath的内联逻辑可能比内置检查更适配这种优化策略。

• 代码组合的连锁效应
  当SafeMath函数和合约其他逻辑结合时，编译器可能会将多个操作的检查逻辑合并，减少重复判断。而内置检查是每个算术操作单独插入，在连续算术操作的场景下，可能产生更多的重复指令，导致gas略高。

总结：0.8.x版本“无需SafeMath”是从安全性和代码简洁性角度的普遍建议，但并非在所有场景下都能带来gas优势。如果追求极致gas优化，建议结合你的业务场景、使用的编译器版本和优化配置，做针对性的对比测试，再决定是否保留SafeMath。

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