不成立——二者为独立实现，标准未要求内存布局一致；虽主流编译器下通常兼容，但在模板特化、跨abi传递、odr违规、const正确性、初始化语法、迭代器类型、重载解析及pch残留等场景存在风险。
boost::array 和 std::array 的二进制兼容性是否成立
直接替换头文件和命名空间通常能跑通，但不意味着安全——boost::array 和 std::array 是独立实现，标准未要求它们内存布局一致。虽然主流编译器（GCC、Clang、MSVC）下同类型同大小的 std::array<t n></t> 和 boost::array<t n></t> 通常二进制兼容，但一旦涉及模板特化、自定义分配器或跨 ABI 边界传递（比如 DLL 导出函数参数），就可能崩溃或读错数据。
- 如果
boost::array出现在头文件中被多个翻译单元包含，且没做 ODR 保证，迁移后可能引发链接时符号不一致 - 若代码里取过
&arr[0]并传给 C 接口，两者行为一致；但若依赖boost::array的额外成员（如.data()返回const T*而非T*的旧版本），std::array可能返回非常量指针，触发 const 正确性问题
std::array 的构造与初始化写法差异
std::array 不支持隐式聚合初始化（C++17 前尤其明显），而 boost::array 更宽容。例如 boost::array<int> a = {1, 2};</int> 在老 Boost 版本中合法，但换成 std::array 后可能报 “no matching constructor”。
- 显式使用统一初始化：
std::array<int> a{1, 2};</int>（推荐，C++11 起支持） - 避免
= {1, 2}形式赋值，尤其在类成员初始化列表中，某些编译器会拒绝 - 若原代码用
boost::array::assign()，需改用std::fill(a.begin(), a.end(), val)或循环赋值，std::array没有assign成员
迭代器和范围遍历的隐含陷阱
两者都提供 begin()/end()，但 boost::array 的 const_iterator 类型在部分 Boost 版本中是 T const*，而 std::array 统一为标准库迭代器类型（通常是 T* 或封装指针）。这会影响 ADL 查找、SFINAE 判定，以及某些泛型算法对 iterator_traits 的假设。
- 检查是否用了
boost::make_array——std::array无对应工具，需手写std::array{...}或用辅助函数推导 - 若代码依赖
boost::array::rbegin()返回reverse_iterator<t></t>，std::array行为相同，但确保没对迭代器类型做static_cast强转 - 用
for (auto& x : arr)安全；但若写了for (int* p = arr.begin(); p != arr.end(); ++p)，需改为for (auto p = arr.begin(); p != arr.end(); ++p)，避免类型不匹配
模板参数推导和函数重载冲突
当函数模板同时接受 boost::array 和 std::array 时，迁移后可能触发意外重载解析。例如一个函数接受 boost::array<t n></t>，另一个接受任意容器，替换后编译器可能选中后者，因为 std::array 满足更多概念约束。
- 搜索所有
boost::array出现的位置，包括函数声明、using 声明、模板参数默认值 - 特别注意
typedef boost::array<...> my_array;</...>这类别名，它们不会自动转向std::array，必须手动替换 - 若项目用了
BOOST_NO_CXX11_HDR_ARRAY等宏控制头文件包含，迁移到std::array后要清理这些宏，否则可能引入重复定义或头文件冲突
最易被忽略的是模板实例化点：如果某个 boost::array 类型在 PCH（预编译头）中被实例化，而迁移后只改了源文件没重建 PCH，旧符号仍可能被链接进来，导致运行时行为异常。建议全量 clean + rebuild，而非增量编译。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
