std::variant可以进入一种称为“valueless by exception”的状态。
据我所知，这种情况的常见原因是移动赋值引发异常。变体（variant）的旧值不再保证存在，预期的新值也不再存在。
std::optional则没有这种状态。cppreference对此做出了大胆声明：
如果引发异常，则*this的初始化状态…保持不变，即如果对象包含一个值，则仍然包含一个值，反之亦然。
std::optional如何避免变成“valueless by exception”，而std::variant没有呢？
optional<T>有两种状态:
T只有当从一种状态转换到另一种状态时，variant才能进入没有值的状态 - 因为您需要以某种方式恢复原始对象，并且为此采用的各种策略需要额外的存储1、堆分配2或空状态3。
但对于optional，从T转换为空仅仅是一个销毁过程。因此，如果T的析构函数没有抛出异常，在此过程中就不会抛出异常。如果从空转换到T也不是问题-如果抛出异常，也很容易恢复原始对象：空状态为空。
具有挑战性的情况是：emplace()在我们已经有一个T的情况下。我们必须销毁原始对象，因此如果emplace构造函数抛出异常，我们该怎么办？使用optional，我们有一个已知的、方便的空状态回退选项 - 因此设计就是这样做的。
variant由于没有这个易于恢复的状态而引起问题。
1如boost::variant2所做的那样。
2如boost::variant所做的那样。
3我不确定有哪个变体实现可以这样做，但有一个设计建议是如果variant<monostate, A, B>持有一个A并且向B的转换抛出异常，则可以转换为monostate状态。
std::optional很简单:
它包含一个值并且要赋新值：
很容易，只需委派给赋值运算符来处理。即使出现异常，仍将保留一个值。
它包含一个值并要删除该值：
很容易，析构函数不能抛出异常。标准库通常假定用户定义类型不会抛出异常。
它不包含值并要分配一个值：
在构造时遇到异常后返回无值的状态就足够了。
它不包含值且不分配任何值：
微不足道。
std::variant当存储的类型不变时也同样简单。
然而，当分配不同类型时，它必须通过销毁先前的值为其腾出空间，而构造新值可能会引发异常！
由于先前的值已经丢失，那么你可以怎么做？
将其标记为“因异常而无值”的状态，这样可以有一个稳定的、有效但不理想的状态，并让异常传播。
可能需要使用额外的空间和时间来动态分配值，在某个临时位置保存旧值，在赋值之前构造新值或类似的策略，但所有这些策略都是昂贵的，只有第一种策略始终可行。
optional没有这个问题。如果它所包含的对象发生异常，那就让它发生吧。对象仍然存在。这并不意味着对象的状态仍然有意义——它取决于抛出异常的操作所处的状态。希望该操作至少具有基本保证。std::optional::operator= 使用 T::operator= 而不是销毁 + 构造 T 值，这是一个非常重要的细节。emplace 执行后者（如果新值的构造引发异常，则会使 optional 为空）。 - Max Langhof
optional<T>从T转换到另一个T状态的情况。请注意，在过程中如果抛出异常，emplace和operator=的行为是不同的！ - Max Langhofemplace中的构造函数抛出异常，那么将显式声明optional未参与。如果operator=在构造期间抛出异常，那么同样没有值。Barry的观点仍然有效：它之所以有效是因为始终存在一个合法的空状态，可以将optional设置为空。variant没有这种奢侈，因为variant不能为空。 - Nicol BolasT::operator=- 这种特定情况不涉及空的optional或者任何析构函数。由于此答案中涉及std::optional的所有案例都涉及销毁或者空状态，因此我认为这个重要案例（其他答案都没有涉及）被遗漏了。别误会，这个答案完全涵盖了其他所有方面，但我自己还必须阅读这个最后一个案例... - Max Langhof**this = *other的事情。 - L. F.std::variant(或std::optional::emplace)一样破坏并重新创建包含的实例。但我认为这取决于人们认为哪些规范部分是显而易见的，以及什么需要解释。这里的答案在这方面有所不同，它应该涵盖接口可能存在的不同预设。 - Max Langhof