★ FEATURED ARTICLE 1. 先搞清楚C初始化列表到底在说什么如果你在搜索引擎里敲下list Initialization这几个词翻来覆去看到的都是 C 标准文档里干巴巴的条款——initializer-list、braced-init-list、narrowing conversion 这些术语堆在一起新人看了半天还是一头雾水。我自己的经验是与其去背语法条款不如直接从这东西解决了什么问题入手。C 里有好几种初始化方式赋值初始化、括号初始化、列表初始化。C11 引入的列表初始化list initialization是当时改动最大的特性之一核心诉求是统一初始化语法、解决最令人困扰的解析most vexing parse这类历史遗留问题同时提供一种更安全、更严格的类型检查机制。到了 C14、C17、C20这个特性又被反复打补丁、修边角最终演变成今天你在现代 C 代码里看到的样子。这篇文章我不会照着标准文档给你念条款而是把各版本之间真正有行为差异的地方挑出来用实际代码验证给你看。适合什么人来读如果你正在用 C11/14/17/20 写项目并且曾经被std::initializer_list的隐式转换、窄化转换报错、auto推导差异这些问题坑过那这篇的内容就是为你准备的。如果你是刚接触现代 C 的初学者这篇文章也能帮你少走弯路提前避开那些隐藏在看起来无伤大雅的小括号改大括号背后的行为差异。2. 版本更迭背后的设计动机为什么非要搞出这么多规则2.1 列表初始化要解决的三件历史大事先说背景。C03 时代初始化对象的写法五花八门int x(5)、int y 5、int arr[3] {1,2,3}、std::vectorint v(10, 20)、MyClass obj MyClass(1,2)。这不仅仅是风格不统一的问题它直接导致了两个著名痛点。第一个痛点是最令人困扰的解析。你看这一行代码Widget w();C03 编译器会把它解析成函数声明——一个名为w、不接受参数、返回Widget的函数。如果你的本意是想定义一个名为w的 Widget 对象这种写法在 C03 里根本做不到只能改用Widget w;或者Widget w{};。C11 之前大家的规避手段很不优雅有人用Widget w;有人用Widget w Widget();项目里风格五花八门。第二个痛点是聚合类型和非聚合类型的初始化方式割裂。数组、结构体可以用{}批量初始化但 STL 容器不行。std::vectorint v {1,2,3}这种写法在 C03 里是错的你得先构造一个临时数组再拷贝进去或者老老实实push_back三次。这在代码可读性上是一个很大的退步。第三个痛点是防止收缩转换窄化转换导致的信息丢失。C 传统的隐式类型转换里int i 3.14;编译器顶多给个警告甚至有些编译器在默认参数下连警告都不给直接截断成 3。但这种转换往往是 bug 的温床。列表初始化想做的更绝——如果转换过程中可能丢失信息直接编译报错不给你侥幸过关的机会。2.2 统一初始化口号下的现实妥协理想很丰满现实很骨感。C11 的列表初始化虽然被称为统一初始化但实际上并没有做到真正统一。委员会花了很大力气把这个特性塞进了语言里结果就是不断有人踩坑std::vectorint v{10, 20}和std::vectorint v(10, 20)语义完全不同auto x{1}在不同标准下推导结果甚至不一样。这些差异不是标准委员会粗心大意而是列表初始化作为一个新引入的语法要和既有的重载决议规则、模板推导规则共处必然产生摩擦。后面几个版本的修订本质上都是给这些摩擦打补丁。我在项目里见过最典型的现象团队里老人们写代码习惯能不加大括号就不加新人则因为学了现代 C 推荐大括号初始化而大量使用{}。两拨人对同一段代码的理解经常产生分歧代码评审时吵成一团。要真正理解这些差异就得从各个版本的规则细节入手。3. C11 里的初始值设定项列表新语法诞生记3.1 花括号的语义变迁从聚合初始化到通用初始化C11 之前{}只用于聚合类型的初始化。所谓聚合类型大致可以理解为一个没有用户自定义构造函数、没有私有成员、没有基类和虚函数的类或数组。{1, 2, 3}可以初始化数组、可以初始化struct Point { int x; int y; };但碰不了std::vector。C11 引入了std::initializer_listT这个标准库类型以及一套与之配套的重载决议规则。当一个类拥有接受std::initializer_listT的构造函数时用花括号初始化这个类时就会优先匹配这个构造函数。这就是std::vectorint v{1, 2, 3}能够工作的底层机制——std::vector在 C11 里新增了vector(std::initializer_listT)这个构造函数。那编译器是怎么知道{1, 2, 3}应该生成一个initializer_listint呢这涉及到模板推导和隐式转换的配合。当你写auto il {1, 2, 3};时编译器会为花括号内的每个元素执行一个叫做复制列表初始化的过程把它们放到一个隐藏在幕后的数组中然后让initializer_listint指向这个数组。这个数组的生命周期是怎样的标准的说法是其生命周期和initializer_list对象一样长。实际项目中你不会直接感知到这个细节但你得知道一点std::initializer_list只是视图不是容器你不能把它当std::vector用——没有size()之外的任何成员函数可以修改内容。3.2 窄化转换检查宁可报错不愿出错列表初始化最让 C 程序员又爱又恨的规则就是窄化转换检查。规则本身不复杂如果初始化列表里的某个值无法在不丢失信息的前提下转换成目标类型编译不给过。int x{3.14}; // 编译错误浮点转整型可能丢失信息 int y{3}; // 正确 int z{1234567890}; // 正确 char c{300}; // 编译错误300 超过 char 的表示范围 double d{1}; // 正确整型转浮点1 可以被精确表示这里有个容易被忽略的边界情况const int ci 3.14; int x{ci};如果ci是常量表达式编译可以通过因为编译器能在编译期算出 3 这个值确认它不超范围。但如果ci是运行期变量编译就会报错。同一段代码在优化开与不开的情况下行为一致但在值显然可判断与值在编译期不可判断两种情形下编译器有不同的处理路径。用一句话总结我的经验列表初始化在编译期做了更多的值分析工作因此报错更早、更严格。由于这个特性很多现代 C 风格指南都强烈推荐使用{}初始化基础类型变量。我个人的看法是这个建议有道理但要付出代价int a{0}看起来确实比int a 0严谨但代码里大量出现这种写法反而干扰阅读。我见过某些人用{}初始化一切的时候遇到真正的 bug 反而被过早的编译错误掩盖了更根本的设计问题。3.3 std::initializer_list 与重载决议的优先级经典的坑这是整个 list initialization 里最坑、也最值得展开讲的一个点。看看这段代码#include vector std::vectorint v1(10, 20); // 构造 10 个值每个都是 20 std::vectorint v2{10, 20}; // 构造只有两个元素 {10, 20} 的 vector如果你不假思索地以为{}只是把()换成了颜值更高的大括号那就掉进陷阱了。v1(10, 20)调用的是vector(size_type count, const T value)构造函数创建包含 10 个 20 的容器。v2{10, 20}调用的是vector(std::initializer_listint)构造函数创建包含两个元素 10 和 20 的容器。为什么会这样因为 C11 里有一条铁律当类的构造函数列表中既有initializer_list构造函数、又有普通构造函数时只要花括号初始化中提供的值能隐式转换成initializer_list的元素类型编译器就优先选择initializer_list构造函数。这优先级不是倾向而是碾压。就算普通构造函数参数类型和数量匹配得更好也干不过initializer_list。看一个更隐蔽的例子。如果某个类的重载是MyClass(int, int)和MyClass(std::initializer_listint)那么MyClass x{3, 4};一定调入后者。如果这个类的initializer_list构造函数需要的元素类型是int而实参是double规则是窄化转换优先于换用普通构造函数。我在实际项目里踩过一次这个坑当时写了一个容器类既有Container(size_t count, const Element value)也有Container(std::initializer_listElement init)。代码里到处用Container(5, hello)创建 5 个hello字符串。后来某一天我为了风格统一把所有小括号改成大括号结果行为立刻变了——Container{5, hello}匹配了 initializer_list 构造函数创建了一个只有两个元素的容器一个是整数 5 转成的字符串5一个是hello。这个 bug 在单元测试里抓出来的当时排查了很久才意识到是括号选择惹的祸。从那以后我在项目里立了一条规矩构造函数调用到底用()还是{}取决于你想要哪种语义而不是风格偏好。3.4 auto 花括号C11 的推导规则C11 刚发布时auto x{1};被推导为std::initializer_listint。这是个让很多人困惑的决策——直觉上x应该是int才对。标准委员会在 C17 里修正了这个行为后面细说但 C11/14 时代写过大量这类代码的人肯定都被坑过。auto x{1}; // C11/14: std::initializer_listint auto y {1}; // C11/14: std::initializer_listint auto z{1, 2}; // C11/14: std::initializer_listint你可能会想既然都推导成initializer_list那x和y有什么区别在 C11/14 里二者确实是一样的。但在 C17 里auto x{1}变成了int而auto y {1}仍然是std::initializer_listint。如果哪天你升级了编译标准本来打印x内容的代码从打印一个整数突然变成了打印一个容器这波行为变化确实会让旧代码措手不及。4. C14 的微调与 C17 的修正从细节差异到标准变迁4.1 C14大方向未变规则更清晰C14 在列表初始化上几乎没做什么惊天动地的改变基本都是清理和明确。上面提到的花括号初始化、窄化转换、initializer_list重载优先级这些规则在 C14 里基本原样保留。C14 的核心关注点在泛型 lambda、返回类型推导这些其它特性上list initialization 并没有被列为重点。但这不代表 C14 阶段没有任何值得注意的实践变化。随着 C14 编译器逐渐普及实际开发者开始更广泛地使用{}初始化原本 C11 引入的规则在工程层面被大规模验证。这个阶段涌现了大量有关统一初始化陷阱的文章和讨论很多团队在这个时期第一次大规模品尝到了花括号带来的困惑。4.2 C17auto 推导修正与新增规则C17 对 list initialization 做了几个关键修正其中最有代表性的就是auto从花括号初始化的推导规则。在 C17 开始auto x{1};推导为intauto x{1, 2};直接编译错误——因为单一元素花括号不再自动包成 initializer_list而多元素花括号无法推导出一个确定的元素类型来构造。换句话说写法C11/14 推导结果C17/20 推导结果auto x{1};std::initializer_listintintauto x{1, 2};std::initializer_listint编译错误auto x {1};std::initializer_listintstd::initializer_listintauto x {1, 2};std::initializer_listintstd::initializer_listint这个修正背后的逻辑很清晰auto的语义是推断出变量的真实类型如果写成auto x{1}结果却是initializer_listint这让很多人感到莫名其妙。C17 把这种花括号自动包成 initializer_list的行为限制到必须有等号的复制列表初始化里有等号意味着程序员明确表达我要做列表初始化。C17 还有一个重要的新增能力拷贝省略copy elision在新标准里变成强制行为。这件事和列表初始化结合起来后就非常微妙。看这段代码struct Point { int x; int y; }; Point make_point() { return {3, 4}; // 用列表初始化返回值 }C17 以前如果Point有移动构造函数和拷贝构造函数编译器返回{3,4}时可能产生临时对象再拷贝/移动C17 之后纯粹的按值返回 prvalue 直接被构造到目标位置连移动构造都不用调。这带来的是语义保证的变化你写return {3, 4}实际上就是在构造返回值对象而不是构造一个临时对象再去移动。对于不再有意义的临时对象C17 做出了更干净的语义统一。4.3 C17 的类模板实参推导CTAD如何影响初始化C17 最大的新特性之一是 CTADClass Template Argument Deduction实参可以让编译器自动推断模板类型。比如std::pair p{1, hello}; // 推导为 std::pairint, const char* std::vector v{1, 2, 3}; // 推导为 std::vectorint注意这里的std::vector v{1, 2, 3}和 C17 之前必须写std::vectorint v{1, 2, 3}有本质区别——编译器根据花括号里的元素推断出元素类型是int。CTAD 和 list initialization 结合后产生了一个很微妙的交互如果你写std::vector v{1, 2, 3}推断过程主要依赖 initializer_list 构造函数——元素类型为int所以v是vectorint。但如果你写std::vector v(1, 2)则编译错误因为 CTAD 首先尝试的是普通的(T, T)构造函数推导但第一个参数1的类型是int第二个参数2的类型也是int匹配不上(size_type, T)。这段推导规则很容易被误解我经常看到一个说法CTAD 会优先匹配 initializer_list 构造函数——严格说这不准确。CTAD 的推导过程确实会考虑 initializer_list 构造函数但推导依据是初始化方式是列表初始化还是括号初始化。C17 有一条很长的推导规则清单但用我实践里的经验可以概括成一句话你用什么形式的括号推导就优先往哪个方向的构造函数靠。用{}初始化容器时推导更倾向于生成一个initializer_list元素的容器。5. C20 的新增变化指示符初始化和更多细节5.1 指示符初始化Designated InitializersC20 给 list initialization 增加了一个 C 语言早就有的特性指示符初始化。你可以直接通过成员名指定要初始化的字段struct Config { int timeout_sec; int retry_count; std::string endpoint; }; Config cfg{ .timeout_sec 30, .endpoint https://api.example.com };这个特性在 C 语言里很常见C20 终于补上了。要注意的是它的规则比 C 更严格C20 要求指示符的顺序必须和成员声明顺序一致不能跳着初始化也不能重复初始化同一个成员。比如上面那个例子中你先写.endpoint再写.timeout_sec就是编译错误。这个特性对实际工程的好处非常大。以前初始化一个字段很多的结构体要么按位置写一长串值让人不知所云要么用构造函数的参数名去猜测对应关系。有了指示符初始化字段名就写在代码里读起来一目了然。对于只有 public 数据成员的 POD 类或聚合类来说这是 C20 给列表初始化带来的最实用的增强。5.2 括号初始化中的一些边界规则修正C20 还规范了一些奇怪的边界行为。比如在 C20 之前new Point{1, 2}和new Point(1, 2)在某些场景下的语义差异并不明确C20 明确采用了花括号初始化一贯的原则窄化转换检查同样适用于 new 表达式中的列表初始化。还有就是在模板非类型参数中字符串字面量的列表初始化在 C20 中有了一些更具体的规则变化不过这个用法在日常工程中比较少见这里不展开。我更想讲的是 C20 里和 list initialization 耦合比较深的另一处变化约束concepts。约束和重载决议的交互让initializer_list构造函数的选择过程更复杂了。举个例子如果你定义了一个带 Concept 约束的构造函数和另一个 initializer_list 构造函数编译器的裁决逻辑不再只是简单的initializer_list 优先而是先检查约束是否满足。约束不满足时可能选择另一条路。虽然我在实际项目里很少把 concepts 和 initializer_list 混在一个类里设计但确实见过有人用概念约束来抑制initializer_list 的绝对优先权做法是给普通构造函数加上 requires 子句使它在语义上比 initializer_list 更匹配。这类技巧需要你同时理解概念约束和重载决议规则算是一个进阶用法。5.3 C20 中 initializer_list 的实现细节观察C20 标准库层面没有对std::initializer_list本身做大规模改动但我发现编译器实现和行为在这个阶段趋于稳定值得分享几个实际观察到的现象。第一花括号初始化表达式生成的底层数组其生命周期规则在主流编译器中基本一致——在函数内部创建 initializer_list 时底层的数组生命周期通常和 initializer_list 对象一致。但如果你试图把 initializer_list 返回后继续使用标准其实没有保证这是安全的我强烈建议不要这样写。第二在 C20 之前初始化列表中的字符串字面量类型推导偶尔会让新人在写std::setstd::string s{hello, world}时产生困惑花括号里的元素是const char*但目标容器元素是std::string这里发生的是隐式转换。C20 的规则依然如此但这个隐式转换是不是在 CTAD 推导时也能生效答案是CTAD 推导时不会自动做这个转换——std::set s{hello, world}推导出的元素类型是const char*这和很多人以为的应该推导出 string完全不同。如果你写成std::set s{std::string(hello), std::string(world)}推导结果才是std::setstd::string。6. 各版本核心差异对照表一眼看清行为分界线6.1 语法行为对照总表这里我把各版本关键差异整理成一张表方便对照查阅。行为C11C14C17C20窄化转换检查有有有有auto x{1};推导结果initializer_listintinitializer_listintintintauto x{1,2};推导结果initializer_listintinitializer_listint编译错误编译错误返回语句列表初始化使用临时对象拷贝/移动同左由 prvalue 直接构造强制拷贝省略同左指示符初始化无无无有约束对 initializer_list 重载的影响无无无有6.2 不同标准下的老代码迁移策略如果你的项目正在从 C11/14 迁移到 C17/20除了新功能以外最需要关注的就是 auto 加花括号的推导行为变化。这属于看起来能编译通过但语义悄悄变了的一类问题比直接的编译错误更危险。我实际操作中会这样处理先把编译标准切到 C17开启-Werror把警告当错误然后全项目编译。编译器会直接标出auto x{1}可能产生语义变化的点。然后逐个检查这些点如果代码的本意是容器里有 1 这个元素那么 C17 下必须改成auto x {1};或std::initializer_listint x{1};如果本意就是整数 1那auto x{1}反而更符合直觉。从 C11 迁移到高版本时我建议做一次专门的代码审查而不是被动地等编译器报告错误——因为这类语义漂移并不会总是报错。7. 实战排查案例初始化列表引起的行为漂移7.1 案例一vector 大小 vs 元素混淆这是个非常经典的场景。团队里有人写了这样一段代码std::vectorint v{10};他原本想创建一个包含 10 个元素的 vector每个元素默认初始化为 0。但实际上这段代码创建的是只有一个元素、且这个元素的值是 10的 vector。要创建 10 个默认初始化的元素应该写成std::vectorint v(10)。这类 bug 在代码评审时几乎看不出来因为{10}在视觉上太像10 个东西。我在企业项目里做过一个小调查给一组有三年左右经验的开发者看这段代码大概有三分之一的人会搞错语义。为什么会犯这个错因为大家习惯了vector(size_type count)这种构造语义下意识把大括号也当成10来处理。但 C 的重载决议规则不吃这一套——只要存在 initializer_list 构造函数且花括号里的值能转换成元素类型它就赢了。排查这类问题的方法其实很简单不要靠猜靠调试。在 vector 构造完成后立刻打印size()一眼就能看出差别。但更值得反思的是代码里的歧义如果能在写的时候避免就不要留到排查的时候。我在自己的代码里刻意遵循一个原则当构造函数的语义可能产生歧义时优先使用具名函数或显式构造方式。比如创建 10 个 0可以写std::vectorint v(10, 0);如果要创建单元素 vector 就写成std::vectorint v{10};并且在旁边注释这个语义是列表包含 10。7.2 案例二返回语句中的临时对象生命周期另一个我印象深刻的案例和返回语句有关。在 C14 时代代码是这样的std::vectorint get_data() { return {1, 2, 3}; }这段写法在 C11/14 下会构造一个临时 vector然后调用移动或拷贝构造函数把临时对象搬回去。如果你在类里手动实现了移动构造函数并打印日志每次调用get_data()都会看到移动构造日志。到了 C17由于强制拷贝省略临时 vector 直接被构造到调用方的内存位置移动构造日志消失了。这个变化对大多数程序没有实质影响但如果你依赖副作用比如在移动构造函数里更新资源计数器、输出日志、重置指针行为变化会导致你的调试信息突然减少或者资源计数逻辑错乱。我在迁移 C17 时就遇到过一件事某个类的移动构造函数里有个静态计数变量用来追踪临时对象数量结果升级后数量归零。排查了很久才意识到不是代码逻辑错了而是 C17 不再创建临时对象了。从那以后我在设计移动构造函数时尽量减少副作用的依赖因为 C17 已经明确改变了 prvalue 的生命周期模型。7.3 案例三CTAD 推导与字符串字面量的不解之缘最后一个坑是关于 CTAD 加字符串的。我们曾经有一段代码std::mapstd::string, int config{ {timeout, 30}, {retry, 3} };这段代码本身没问题。但在做 CTAD 重构时有人想省略模板参数把它改成std::map config{ {timeout, 30}, {retry, 3} };结果推导出来的类型是std::mapconst char*, int不是std::mapstd::string, int。原代码里后续所有用std::string和 map 键交互的地方都因为类型不匹配而编译失败。虽然代码很快就改回去了但这个案例很好说明了 CTAD 的推导规则initializer_list 的元素类型就是花括号中表达式的静态类型不会为了匹配目标容器元素类型而做隐式转换。字符串字面量就是const char[N]推导成const char*是正确的推论但和人类的直觉相悖。遇到这类问题我的习惯是CTAD 只用在类型非常直观的场景比如std::pair p{1, 2}、std::vector v{1, 2, 3}。一旦牵扯到字符串字面量、隐式转换、嵌套初始化就老老实实写出模板参数不要去赌编译器的推导能力。8. 现代 C 里怎么写出既安全又可读的初始化代码8.1 推荐的核心策略按语义选择括号经过这么多年和各种版本的反复磨合我自己形成了一套比较稳定的初始化风格核心思想概括为先想清楚你想表达的是元素序列还是构造参数。如果你要表达的是这个容器里装这几个元素用花括号std::vectorint primes{2, 3, 5, 7, 11}; std::mapstd::string, int scores{ {alice, 100}, {bob, 90} };如果你要表达的是用这些参数去调用构造函数产生一个特定容量/特定配置的容器用圆括号std::vectorint zeros(100, 0); // 100 个 0 std::string repeat(10, a); // aaaaaaaaaa对于普通类对象的初始化如果构造函数参数没有歧义我倾向用圆括号因为圆括号一直是 C 里最传统的构造方式且不会有 initializer_list 劫持的隐忧。只有当初始化列表本身就是构造对象的核心语义比如聚合类型的批量赋值时我才用花括号。这种风格不能完全避免所有坑但能把代码的意图表达得更清晰。代码评审的时候看到std::vectorint v{10};读代码的人能立刻意识到这是在构造单元素容器因为他了解你的风格约定花括号表示元素序列。如果代码风格混乱有时花括号表示序列、有时只是把括号换成花括号那这个坑就会反复出现。8.2 使用 static_cast 与显式构造来规避窄化歧义窄化转换检查虽然严格但它不是万能的。它只针对编译期可判定的值做严格检查如果转换发生在运行期比如函数参数列表初始化也无法拦截。举个例子void set_volume(float vol); set_volume({0.8}); // 如果 vol 声明为 float没问题 void set_percent(int pct); set_percent({0.8}); // 编译错误double 到 int 窄化编译错误可以帮助你尽早发现类型不匹配但有时候这种严格反而碍事。比如你确实想故意截断一个浮点数int x{static_castint(3.99)}; // 明确意图编译通过这时显式转换的意义不只是骗过编译器更是向代码阅读者传递我知道这里可能会丢精度这是故意的。我在算法代码里经常需要把浮点数转成整数索引一律使用static_castint不仅是让编译器闭嘴更重要的是下次有人看代码时不会误以为这是无精度损失的操作。8.3 对团队代码规范的实操建议如果你在团队里推行现代 C 的初始化风格我建议不要直接写一律使用花括号初始化这种粗暴规则因为前面已经论证过花括号在某些场景下会改变语义。可以尝试这样几条约定对于基础类型变量优先使用加字面量如int count 0;简单直白不涉及任何列表初始化解析。对于数组和聚合结构体使用花括号因为它是唯一正确的选择。对于容器和类类型的构造默认使用圆括号除非你明确需要 initializer_list 构造语义。当代码中用花括号初始化std::vector、std::map等容器时一定要让周围的代码上下文和注释支撑这个语义防止读者误会。这四条规则不是金科玉律不同团队可以根据自己的代码基础做调整。但核心原则是一致的不要让哪种括号变成一个靠猜的问题。我在好几个项目里都见过因为括号风格混乱代际传递的 bug最终都是靠统一规范解决的。9. 从 C11 到 C20一个值得深入理解的语言演化片段list initialization 是一个特别好的观察窗口它展示了标准委员会如何在语言演进中平衡统一体验和兼容旧代码之间的矛盾。C11 刚推出时不完善的 auto 推导在 C17 被修正C20 又引入了指示符初始化。这些变化不是一次大爆炸完成的而是一步步打补丁、修边角的结果。从我的经验来看任何涉及初始化的大规模重构都不要一把梭升级完编译标准就宣布结束。重点检查所有涉及auto加花括号、容器构造、返回语句列表初始化的代码点。C17 的强制拷贝省略带来的临时对象生命周期变化往往是最隐蔽的不容易被测试覆盖到只有在生产环境的资源管理类里才会突然爆出问题。我自己的体会是学这个主题不要只背版本差异而是要把大括号 vs 小括号当成语言语义的一部分来理解而不是一种风格偏好。每当你看到一段用花括号初始化的代码可以在心里问一句这里调的是哪个构造函数推导结果是什么如果我能快速答出这两个问题那基本不会在这个领域踩坑。最后分享一个我在项目里用的小技巧在代码库里做一个 grep 搜索\{\d\}这种简单花括号初始化把结果拉出来逐一检查语义。通常能发现不少想创建 N 个元素实际创建了单元素容器的潜在问题。这类问题往往是安静的、潜伏的不会报错只会在某个边界条件下让程序行为不符合预期。检完这一轮之后对代码的信心会提升不少。
阅读完成 · 觉得有帮助？
