嵌套花括号是明确二维数组“行边界”的唯一方式，决定列数约束、行数推导、补零位置及编译通过性，省略则导致内存顺序填充或编译错误。
嵌套花括号必须匹配列数，否则编译器会按内存顺序“拉平”填充
嵌套花括号不是语法强制要求，但它是唯一能明确表达“行边界”的方式。如果你写 int arr[2][3] = {{1,2}, {4,5,6}};，编译器会接受；但若写成 int arr[2][3] = {{1,2,3,4}, {5,6}};，就会报错：超出每行容量。因为内层花括号隐含了“该行最多容纳多少列”的约束——列数由声明时的第二维固定（这里是 [3]），内层初始化值不能超过 3 个。
不加嵌套时，比如 int arr[2][3] = {1,2,3,4,5,6};，编译器直接按内存布局顺序填：前 3 个进第 0 行，后 3 个进第 1 行。这种写法容易误判逻辑分组，尤其在留空或部分初始化时。
- 嵌套花括号只影响可读性和错误检查，不改变内存布局
- 省略内层括号后，一旦初始值个数不足，补零位置取决于总偏移，而非“某行末尾”
- 混合写法如
{{1}, {4,5,6}}是合法的：第一行只给一个值，其余自动为 0；第二行填满
省略第一维大小时，嵌套花括号是必需的
当你让编译器推导行数，比如 int arr[][3] = {{1,2,3}, {4,5,6}};，就必须用嵌套花括号。否则 int arr[][3] = {1,2,3,4,5,6}; 会编译失败——编译器无法从一维列表反推出行数，除非你显式切分行。
这个限制常被忽略，尤其在宏定义或模板参数中传入数组字面量时。如果封装成函数参数，还可能触发类型退化（变成指针），进一步掩盖问题。
-
int arr[][3] = {{1,2}, {4}};推出 2 行，每行按[3]补零 → 等价于{{1,2,0}, {4,0,0}} - 不写嵌套、又省略第一维 → 编译错误：
expected ‘{’ before ‘=’ token - 即使所有行都填满，也必须用嵌套形式，否则推导失败
初始化为全零时，{0} 写法依赖嵌套结构的“首元素”语义
int arr[3][4] = {0}; 能清零，是因为 C++ 规定：当初始化列表只提供一个值且为 0 时，整个聚合体（包括所有嵌套子数组）递归零初始化。但这只对静态存储期数组可靠；对栈上局部数组也成立，但对 new int[3][4] 动态分配无效——后者根本不能用 {0} 初始化。
真正安全的全零方式是显式嵌套：int arr[3][4] = {{0}};。双层括号确保第一行第一个元素为 0，触发整块零填充；单层 {0} 在某些老编译器或严格模式下可能被质疑是否覆盖全部维度。
-
{{0}}明确告诉编译器：“第 0 行第 0 列是 0”，其余由规则补零 -
{0}是惯用简写，但属于“宽松零初始化”，不保证跨平台行为一致 - 用
std::array<:array>, 3> = {};</:array>更现代，空初始化列表直接全零，无歧义
C++11 后仍需警惕：列表初始化与聚合初始化的边界
虽然 C++11 引入统一初始化语法，但二维数组仍是聚合类型（aggregate），不支持构造函数。所以 int arr[2][3]{ {1,2,3}, {4,5,6} };（无等号）是合法的聚合初始化；而 int arr[2][3] = { {1,2,3}, {4,5,6} };（带等号）是复制初始化——两者效果相同，但语义不同。某些模板元编程场景下，编译器会对初始化方式做 SFINAE 检查，导致意外失败。
更隐蔽的是，如果把二维数组包进结构体，再用 {} 初始化，嵌套层次就多了一级，容易漏括号或错位。
- 聚合初始化不要求等号，但加等号也不报错（兼容 C 风格）
- 避免混用：比如
int arr[2][3] = { {1,2}, 4,5,6 };是非法的——不能一部分嵌套、一部分扁平 - 调试时看汇编或
sizeof结果，能快速验证是否真按预期分块初始化
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
