为何C++11中std::exception的析构函数未标记为noexcept？

这个问题戳中了C++从98到11版本中异常处理模型的核心变化——简单来说，这是标准委员会在静态强制约束和实际开发灵活性之间做出的平衡调整，背后有几个关键原因：

• C++98的throw()是个“过于严格的紧箍咒”
  在C++98里，std::exception的析构函数标记为throw()，这是一种静态异常说明：它向编译器承诺“这个函数绝对不会抛出任何异常”。如果你的代码不小心在析构里抛出了异常，程序会直接调用std::terminate()终止运行。更麻烦的是，派生类的虚析构函数必须严格继承这个约束——也就是说，std::bad_alloc、std::runtime_error这些派生类的析构也必须是throw()，连尝试放宽都不行，否则编译器直接报错。
  但实际开发中，这种静态检查带来了很多困扰：比如模板代码里，你很难提前确定某个类型的析构函数是否符合throw()要求，很容易触发莫名其妙的编译错误；还有一些极端场景下，开发者确实需要在析构中处理异常（虽然这绝对不是推荐实践），但throw()直接堵死了这条路。

• C++11重构了异常保证模型：从静态检查到运行时兜底
  C11彻底废弃了旧的静态异常说明（除了throw()被等价为noexcept(true)），引入了noexcept这个更灵活的运行时标记。对于析构函数，C11默认就赋予了noexcept(true)的保证——也就是说，除非你显式标记为noexcept(false)，或者类里的成员/基类析构是noexcept(false)，否则析构函数默认是不允许抛出异常的，一旦抛出就会触发std::terminate()。
  那为什么std::exception的析构函数不显式写noexcept(true)呢？其实核心是给派生类留了一丝“选择权”：虽然标准强烈不推荐，但如果某个派生类确实有特殊需求（比如兼容非常老旧的代码），可以显式标记自己的析构为noexcept(false)。不过要注意，如果你通过std::exception*指针调用这个派生类的析构函数，因为基类析构的默认noexcept(true)保证，一旦抛出异常还是会直接终止程序——这既保留了C++98的安全性，又给极端场景开了个小口子。

• “允许抛出”其实是个误解：本质是放宽了静态约束，而非放松了运行时安全
  你可能觉得C11允许析构抛出异常，但实际上，运行时的兜底机制和C98是一样严格的：只要析构函数抛出异常，程序还是会挂掉。差异只在于编译阶段的检查：C98是强制静态检查，不允许任何偏离；C11则是默认安全，同时允许开发者主动选择承担风险。这种调整是因为标准委员会意识到，静态检查带来的编译负担和灵活性损失，已经超过了它能提供的安全价值——毕竟大部分开发者都不会在析构里乱抛异常，默认的noexcept(true)已经足够保证安全。

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