数组退化为指针仅发生在函数参数传递时，形参无论声明为int arr[]、int arr[n]还是int arr，均被编译器视为int，导致sizeof返回指针大小而非数组长度，此行为由c++标准强制规定，且仅限该上下文。
数组退化为指针发生在函数参数传递时
当你写 void func(int arr[10])，编译器根本不会检查你传进来的数组是不是真有 10 个元素；它只把 arr 当作 int* 处理。这不是语法糖，是 C++ 标准强制规定的行为——所有数组形参（无论写成 int arr[]、int arr[5] 还是 int* arr）都会被降级为指针类型。
常见错误现象：sizeof(arr) 在函数内永远返回指针大小（通常是 4 或 8 字节），而不是原始数组总字节数。哪怕你在调用处写了 int data[100]; func(data);，func 里也完全不知道 data 原来有多大。
- 这是为了效率：复制整个数组开销太大，传地址最轻量
- 但代价是丢失尺寸信息，必须靠额外参数或容器封装来补救
- 注意：退化只发生在“作为函数参数”这一特定上下文，不是所有地方都退化（比如
&arr或sizeof(arr)在定义作用域内仍能拿到完整尺寸）
为什么 sizeof 在函数内外结果完全不同
sizeof 的行为直接暴露了退化是否发生：在定义数组的作用域内，sizeof(arr) 返回整个数组占用的字节数；一旦进入函数，arr 已经是 int*，sizeof(arr) 就只是指针本身的大小。
示例对比：
int a[5] = {1,2,3,4,5};
printf("%zu\n", sizeof(a)); // 输出 20（5 * sizeof(int)）
<p>void f(int arr[]) {
printf("%zu\n", sizeof(arr)); // 输出 8（64 位系统下指针大小）
}</p>
- 这个差异不是 bug，是语言设计的必然结果：类型变了，
sizeof测的就是当前类型的大小 - 别试图用
sizeof(arr)/sizeof(*arr)在函数内算长度——它算的是int*除以int，结果恒为 2（64 位）或 1（32 位） - 调试时如果看到变量类型从
int[5]变成int*，那就是退化正在发生
数组名在表达式中多数时候自动转成指针
除了函数参数，数组名在大多数表达式中也会退化——只要不处于 sizeof、& 或字符串字面量初始化这三种例外场景。
例如：
-
int* p = arr;→arr退化为&arr[0] -
printf("%d", *(arr + 2));→ 等价于arr[2]，依赖退化后的指针运算 -
&arr→ 不退化，类型是int(*)[5]（指向数组的指针），sizeof(&arr)是地址大小，但&arr本身保留了维度信息 -
sizeof(arr)在定义处 → 不退化，测的是整个数组
这种“多数时候退化、少数时候不退化”的规则，是 C/C++ 类型系统底层一致性的体现，不是随意设计的特例。
现代 C++ 更推荐用 std::array 或 std::vector 替代裸数组
裸数组退化带来的尺寸丢失问题，在 std::array 和 std::vector 中不存在：它们是对象，携带大小信息，传参时可按值、引用或 const 引用传递，.size() 始终可用。
例如：
void f(const std::array<int>& arr) {
std::cout & vec) {
std::cout <ul>
<li>
<code>std::array</code> 是编译期固定大小，零开销，适合替代 C 风格数组</li>
<li>
<code>std::vector</code> 动态大小，内部管理内存，避免手动传 size 参数</li>
<li>如果必须用裸数组（比如嵌入式或对接 C API），就老老实实加一个 <code>size_t size</code> 参数，别指望编译器帮你记长度</li>
</ul>
<p>退化本身不是缺陷，而是 C/C++ 对内存控制权和性能优先的设计选择；真正容易被忽略的是——它让“数组长度”变成一个需要程序员显式维护的契约，而不是语言自动保障的属性。</p></int>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
