为何给含std::string的静态对象成员赋值会阻止其完成初始化？

先还原你的核心场景示例代码：

#include <iostream>
#include <string>

struct Test {
    int val;
    std::string unused_string;
};

// 用IIFE初始化静态变量t
Test t = []() -> Test {
    t.val = -2; // 修改t的成员
    return Test{1, ""}; // 返回val为1的临时对象
}();

int main() {
    std::cout << t.val << std::endl; // 输出1而非预期的-2
}

当移除unused_string成员、删掉t.val = -2，或换成简单自定义平凡类型时，输出会变成预期的-2；换成std::vector<int>则和std::string表现一致。背后的核心原因是C++对象生命周期规则、初始化阶段划分，以及非平凡类型的构造逻辑差异：

1. 静态对象的初始化阶段 #

C++中静态存储期对象的初始化分两步：

• 零初始化：程序启动前，所有静态对象的内存会被统一置零。此时t.val为0，unused_string的内部指针、大小等成员也都是0，但它还不是合法的std::string实例——因为std::string的构造函数尚未执行。
• 动态初始化：执行IIFE这类初始化器，完成对象的最终初始化。

2. 平凡类型与非平凡类型的生命周期差异 #

关键区别在于对象生命周期的起始时机：

• 平凡类型（比如仅含int的结构体、无自定义构造/析构的简单类型）：零初始化完成后，对象的生命周期就正式开始——这类类型的“构造”就是内存置零，无需额外逻辑。
• 非平凡类型（比如std::string、std::vector，或包含它们的结构体）：对象的生命周期要等到构造函数执行完毕才启动。动态初始化完成前，它们只是一块被置零的内存，并非合法对象。

3. 不同场景的表现原因 #

含std::string的结构体（非平凡类型） #

你在lambda中修改t.val = -2时，本质是在修改尚未进入生命周期的对象内存——这属于未定义行为。编译器处理时会优先执行后续的动态初始化逻辑：用lambda返回的临时Test{1, ""}对象，在t的内存上完成构造。这个构造过程会覆盖t的所有内存，包括你之前修改的val成员，最终t.val为1。

平凡类型的结构体 #

此时t的生命周期在零初始化后已启动，lambda中修改t.val = -2是合法操作。编译器会优化掉lambda返回临时对象的初始化逻辑——因为t已是合法存在的对象，且你主动修改了成员值，最终保留的就是修改后的-2。

std::vector和std::string的共性 #

二者都是标准库提供的非平凡类型，都有自定义构造/析构函数和内存管理逻辑，包含它们的结构体也会被视为非平凡类型，触发上述构造覆盖行为。

简单自定义非聚合类型输出-2的原因 #

如果你的自定义类型是平凡类型（无自定义构造/析构，所有成员都是平凡类型），其生命周期规则和仅含int的结构体一致，lambda中的修改会被保留，最终输出-2。

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