为什么C++函数默认允许抛出异常而非默认noexcept？

这个设计是C++标准委员会结合多年工程实践权衡后的结果，核心原因有三点：

• 首先是无法回避的历史兼容性包袱
  C从98标准发布到C11引入noexcept，已经有十余年的存量代码积累，这些代码在旧标准下默认都是允许抛出异常的。如果反过来把默认行为改成不抛异常，要求所有会抛异常的函数手动加标注，意味着海量存量代码在升级编译器后会直接出现语义错误：只要函数漏了抛异常的标注，运行时一旦真的抛出异常就会直接触发std::terminate崩溃，迁移成本高到足以让绝大多数开发者拒绝升级标准，这种破坏性变更是C标准设计中会优先规避的。
  实际上C98时代就试过类似「显式标注异常抛出情况」的设计，也就是动态异常规范（比如throw()标注不抛异常，throw(std::bad_alloc)标注只抛指定类型异常），但十几年的工程实践已经证明这条路完全走不通：标注维护成本极高——你改个内部实现换了个依赖函数，异常列表就得跟着改；编译器很难做全覆盖的静态检查，漏标的问题往往拖到线上运行才会炸；最后实际开发里几乎没人好好维护这套标注，要么干脆不写，要么随便写个throw()应付事，根本达不到设计预期，最后这套规范在C++11中被直接废弃，noexcept从设计之初就没打算重走这条老路。
• 其次是默认行为的容错性权衡
  两种默认设计的故障代价完全不对等：
  如果默认允许抛异常，开发者漏标了本应加noexcept的函数，最坏结果只是编译器无法做极致优化（比如移动语义场景下无法优先选择noexcept移动构造，可能产生额外拷贝开销），程序逻辑不会出错，更不会崩溃；
  如果默认是不抛异常，开发者漏标了会抛异常的函数，编译器会默认给函数加上noexcept语义，一旦运行时真的抛出异常，会直接终止程序，这类问题隐蔽性极强，排查成本极高。
  显然，选择「默认安全、顶多损失性能，高收益高风险的优化选项需要开发者主动确认」的逻辑，比「默认可能崩，需要开发者手动补标注规避风险」的设计在工程层面靠谱得多。
• 最后是标注本身的信息效率问题
  普通C++开发中，绝大多数函数天然具备抛异常的可能：调用new可能抛std::bad_alloc、操作STL容器可能抛异常、做IO操作可能抛异常，业务代码只要调用了这类基础组件，本身就属于允许抛异常的范畴。如果要求所有会抛异常的函数手动加标注，那绝大多数函数都要重复加无意义的except标记，标注会变成纯粹的语法噪音，完全失去「给调用者传递明确语义、指导编译器优化」的作用。
  反观现在的设计，只有开发者明确确认函数所有执行路径都不会抛出异常（哪怕内部调用抛出异常也会在函数内部完全处理）时，才需要加noexcept，看到这个标记的调用者可以放心在自己的noexcept逻辑中调用该函数，编译器也可以放心做跳过异常栈展开相关的优化，标注本身的信息量是足够高的。

补充一个容易被忽略的细节：noexcept除了是优化提示，更是函数接口契约的一部分，一旦标注就意味着函数的不抛异常行为是对外承诺的、后续版本也不能随意打破，这种强承诺本身就不应该是默认行为，必须由开发者显式做出。

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