默认 c'tor 的悖论可能会抛出带有 std::string 成员的 class

Question

C++“核心指南”是否阻止（或至少强烈阻止）具有std::string成员的 class 具有默认构造函数？ 我之所以问，是因为我在最“严重”的设置中使用 MSVC 代码分析工具（在 Visual Studio 2019 中）时注意到的一个问题； 问题是“C26455”警告，如本文档中所述：

C++ 核心指南建议默认构造函数不应该做任何可以抛出的事情。 如果允许默认构造函数抛出，则 move 和 swap 等操作也会抛出，这是不希望的，因为 move 和 swap 应该总是成功。 参数化的构造函数可能会抛出。

下面的简单代码示例说明了该问题：

#include <string>

class Person {
private:
    std::string my_name;
public:
    // C26455: Default constructor may not throw. Declare it 'noexcept'...
    Person() : my_name{ "Anonymous" } {}

//  // C26447: The function is declared 'noexcept' but calls function 'allocator<char> >()' which may throw exceptions...
//  Person() noexcept : my_name{ "Anonymous" } {}
};

现在，如果我注意到生成的 C26455 警告（如注释中所示），并将noexcept说明符添加到默认构造函数（在上面的代码示例中被注释掉），我会收到一个不同的警告，表明我的构造函数调用了标准库中可能抛出的例程：

警告 C26447：function 被声明为“noexcept”，但调用 function“分配器 >()”可能会引发异常 (f.6)。

请注意，如果我从构造函数中删除初始值设定项列表并将该默认值初始值设定项添加到my_name成员的声明中（如std::string my_name{ "Anonymous" }; ），我会收到相同的警告。 但是，如果我没有显式初始化my_name成员，所有警告都会消失——这意味着我依赖std::string的默认构造函数来创建一个未指定容量的空 object。

据推测，另一种选择是提供我自己的非抛出分配器，并将其作为第二个参数传递给my_name构造函数——但在我看来，这似乎是一个非常常见的解决方案有点过于复杂用例。 （将其他标准库容器对象用作需要涉及分配的初始化的 class 成员时会出现类似情况。）

这个问题有简单的解决方案吗？ 或者我应该忽略/禁用那些代码分析警告和核心指南？