C++11引入的构造函数调用语法是否已被取代？

嘿，这个观察真的很敏锐！我来帮你拆解清楚这里的来龙去脉——其实C++11那套{}初始化的推荐并没有被“正式撤回”，但随着标准的演进，最佳实践确实发生了变化，而你注意到的拷贝消除强化正是核心原因。

首先得说，你提到的P0475（C20）和P3106（C26）绝对是关键转折点。C++20开始，强制拷贝消除的规则覆盖了更多核心场景：当你写T var = expr;这种形式时，只要expr的类型可以隐式转换为T（或者本身就是T），编译器必须跳过拷贝/移动构造函数的调用，直接把对象构造在var的内存位置里——哪怕你的拷贝构造函数有明显的副作用（比如加了打印日志的代码），编译器也不能调用它。

这就直接解决了C11时代推荐{}的核心痛点：原来担心的Struct var = parameter;会先调用转换构造生成临时对象，再调用拷贝构造的情况，在现代C里已经完全不可能发生了。现在这种写法的性能和Struct var{parameter};完全一致，没有任何额外开销。

另一方面，{}初始化本身也带来了一些当初没预料到的小麻烦：

• 在C11里，auto x{1};会被推导成std::initializer_list<int>而不是int，这个反直觉的问题直到C17才被修正；
• {}初始化会严格禁止窄化转换，比如int x{3.14};会直接编译失败，而int x = 3.14;只会触发警告（或按实现处理）——有时候这是好事，但很多场景下这种严格性反而会打断正常的开发流程；
• 某些情况下，{}会和重载决议交互产生意外结果，比如当类同时有接受std::initializer_list的构造函数和其他构造函数时，{}会优先匹配前者，可能违背你的预期。

正是因为这些原因，加上拷贝消除已经足够可靠，现在的C社区和标准委员会成员，更倾向于在简单初始化场景下使用=语法——你看到C26提案里全是这种写法，就是这个道理。

当然，{}初始化也不是完全没用了：

• 当你需要禁止窄化转换时，它依然是最佳选择；
• 初始化聚合类型（比如数组、简单结构体）时，{}的写法更清晰；
• 遇到“最令人头疼的解析”问题时，比如Struct var();会被解析成函数声明，这时候Struct var{};就能正确创建对象。

总结一下：原来推荐{}的核心理由（避免不必要拷贝）已经被现代C++的强制拷贝消除彻底解决，而{}本身的一些特性在日常使用中可能带来意外，所以现在的最佳实践更偏向于用=初始化——除非你有明确的场景需要{}的特殊行为。

内容来源于stack exchange