现代C++明确将裸数组视为高风险遗留设施，因其触发array-to-pointer decay导致隐式指针转换、丢失长度信息且违背RAII原则。
现代 C++ 不是“建议”淘汰裸数组，而是明确将其视为高风险、低维护、反 RAII 的遗留设施——只要编译器允许，它就该被禁用。
裸数组触发 array-to-pointer decay 导致隐式指针转换
这是最隐蔽也最致命的问题。当你把 int arr[10] 传给函数时，它自动退化为 int*，丢失长度信息，且无法在函数内用 sizeof(arr) 获取真实大小。
- 常见错误现象：
void process(int* p) { std::cout 总是输出 4 或 8（指针大小），而非数组长度 - 使用场景：任何需要传递固定大小数组的接口，比如配置表、硬件寄存器映射
- 替代方案：
std::array<int></int>保留尺寸、支持范围 for、可拷贝、不退化；std::span<const int></const>（C++20）用于只读视图，零开销且带长度
new[]/delete[] 配对极易出错且不异常安全
裸数组一旦动态分配，就必须手动调用 delete[]，而 C++ 异常会直接绕过后续代码，导致 delete[] 永远不被执行。
- 常见错误现象：函数中先
new[]，中间某处抛异常，delete[]被跳过 → 内存泄漏 - 参数差异：
std::vector构造即分配，析构即释放；std::unique_ptr<int></int>同样靠析构保证delete[]执行，且支持移动语义 - 性能影响：二者都无运行时开销；但
std::vector多一次堆分配（可接受），std::unique_ptr<int></int>更贴近裸指针语义，适合底层封装
越界访问无编译期/运行期防护
arr[i] 对任意 i 都合法，编译器不检查，标准库也不拦截 —— 这是缓冲区溢出漏洞的温床。
立即学习“C++免费学习笔记（深入）”；
- 使用场景：嵌入式初始化表、算法临时缓存、图像像素行
- 对比：
std::array::at(i)抛std::out_of_range；std::span::operator[](i)在 debug 模式下可加边界断言；std::vector::at(i)同样带检查 - 容易踩的坑：以为
std::array和裸数组一样“轻”，却忽略它默认不开启越界检查；必须主动用.at()或配合 sanitizer 编译（如-fsanitize=address）
类型系统断裂：无法表达“N 元素数组”作为独立类型
裸数组类型 int[5] 和 int[10] 之间没有继承或转换关系，但它们又都隐式转成 int*，破坏了类型安全契约。
- 典型问题：模板函数
template<typename t> void foo(T*)</typename>接收任意数组，完全丢失维度语义 - 现代替代：
std::array是完整类型，std::array<int></int>≠std::array<int></int>；std::span可约束元素类型与是否可写，例如std::span<int></int>（固定大小）或std::span<const char></const>（动态大小只读） - 兼容性影响：C API 交互仍需
&arr[0]或arr.data()，但这只是桥接，不是理由继续在内部逻辑里用裸数组
真正难处理的从来不是“怎么替换”，而是“要不要在老代码里动第一刀”。一旦开始用 std::array 替换栈上裸数组、用 std::vector 替换动态裸数组，后续所有函数签名、边界检查、生命周期管理都会自然收敛——而那个没改的第一处 int buf[256]，往往就是未来 crash log 里唯一找不到调用栈的地址。
