std::array::size() 是最直接的方式，它返回编译期常量 constexpr size_t，安全、语义清晰且适用于所有 std::array 实例，包括 const 和引用类型，而 sizeof 或 std::size() 存在歧义或陷阱。
std::array::size() 是最直接的方式
std::array 在编译期就确定了长度，size() 成员函数返回的是 constexpr size_t，不涉及运行时开销，也不触发任何隐式转换或临时对象。它比 sizeof(arr) / sizeof(arr[0]) 更安全、更语义清晰。
- 适用于所有
std::array<t n></t>实例，无论是否为 const 或引用类型 - 返回值是编译期常量，可用于模板非类型参数（比如
std::array<int arr.size> tmp;</int>） - 注意：不要和
std::vector::size()混淆——后者是运行时查询，而std::array::size()完全在编译期解析
为什么不能用 std::size(arr)？
std::size()（来自 <iterator></iterator>）对 std::array 确实可用，但它底层调用的正是 arr.size()。问题在于可读性和意图表达：当你看到 std::size(arr)，无法立刻判断 arr 是 array、vector 还是 C 风格数组；而 arr.size() 明确表明这是容器接口调用，且对 std::array 来说，它就是最原生、最无歧义的方式。
- 如果代码中混用多种容器，统一用
std::size()可能带来一致性假象，但实际行为差异（比如对 C 数组退化指针失效）反而容易埋坑 - 某些旧编译器（如 GCC 4.8 之前）对 ADL-based
std::size()支持不完整，而arr.size()始终可靠
sizeof(arr) / sizeof(arr[0]) 的陷阱
这个“C 风格”写法在 std::array 上看似可行，但极易出错：
- 当
arr是引用类型（如const std::array<int>& ref</int>），sizeof(ref)仍是整个 array 的大小，但语义上已失去“类型尺寸推导”的直观性 - 若元素类型是类且重载了
operator sizeof（虽然标准禁止，但误用宏或特殊上下文可能干扰），结果不可靠 - 最致命的是：一旦把
std::array传给接受const T*的函数，数组退化为指针，sizeof就完全失效——而size()不会，因为它是成员函数，只作用于完整对象
模板中获取 N 的几种等效写法
如果你需要在模板里提取 std::array 的长度 N（而非运行时数值），有多个选择，但推荐明确使用 std::tuple_size_v 或直接从模板参数推导：
-
std::tuple_size_v<decltype></decltype>—— 标准定义的 trait，专为元编程设计，支持所有 tuple-like 类型 -
decltype(arr)::size()—— 编译期常量表达式，可直接用于数组声明：int buf[decltype(arr)::size()]; - 避免依赖
std::extent_v：它只对 C 数组有效，对std::array返回 0
真正容易被忽略的是：这些方式都要求 arr 是具名变量或能推导出完整类型；若仅传入 auto&& 且未保留原始类型信息（比如经转发后变成 std::array<int>&&</int>），decltype 仍能正确捕获 N，但若中间经过类型擦除（如存入 std::any 或虚函数参数），所有编译期尺寸信息就彻底丢失了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
