int + 长度参数是嵌入式与高频调用场景下性能最高的方式，因其不封装、不拷贝、不模板推导；而数组引用int(&arr)[n]在多层透传时导致模板爆炸、优化受限且嵌入式编译器支持差；const int + size_t len则是最通用高性能组合，被cmsis、hal等广泛采用。
直接用 int* + 长度参数透传，不封装、不拷贝、不模板推导，是嵌入式与高频调用场景下性能最高的方式。
为什么数组引用 int (&arr)[N] 不适合多层透传
编译期固定大小的数组引用在单层函数中能提供类型安全和边界检查，但一旦涉及两层以上调用（比如 top() → mid() → bottom()），就必须在每一层都显式声明模板参数或重复写死尺寸，导致接口爆炸。更关键的是：GCC/Clang 在 -O2 下对 int (&)[N] 的访问仍会生成带偏移计算的指令，而裸指针可被更激进地寄存器化和循环优化。
- 每增加一层调用，就得加一个
template<size_t n></size_t>声明，代码膨胀且难以维护 - 若中间某层需做尺寸校验或动态分支（如
if (N > 64) {...}），编译期常量反而变成负担 - Keil/IAR 等嵌入式编译器对模板数组引用支持不稳定，容易退化为运行时取地址再算长度
const int* + size_t len 是最通用的高性能组合
这是所有主流 SDK（CMSIS、HAL、LVGL）和 Linux 内核 C 接口采用的模式。它把“数据起始”和“长度”拆开，既避免指针衰减丢失长度，又不引入额外抽象层。
-
const int* data明确表达只读语义，编译器可放心做向量化（如 auto-vectorize for loop） -
size_t len是无符号整型，适配任意平台的地址空间，且不会触发有符号扩展警告 - 调用链上任何一层都可以做
assert(len 或截断处理，无需改签名 - 与 DMA 描述符、ring buffer head/tail 等硬件抽象天然对齐
什么时候该用 std::span<const int></const>？
仅当项目已启用 C++20、且调用深度 ≤ 2 层、且不面向裸机（如 STM32F1 无 STL 支持）时，std::span 才值得考虑。它本质仍是 ptr + size 的封装，但带来两个隐性成本：
- 构造
std::span对象本身有零开销，但某些编译器（如旧版 GCC 11）在内联失败时会保留其成员访问指令 - 若底层函数最终仍要解包成
const int*和size_t，等于白套一层——这在音频处理 pipeline 中很常见 -
std::span无法用于中断服务程序（ISR），因部分实现含异常相关逻辑（即使未抛出）
透传时最容易被忽略的边界陷阱
性能再高，越界一次就全盘失效。多层透传中最隐蔽的问题不是指针本身，而是长度值在各层间被无意修改或截断：
- 用
int存长度 → 在 64 位系统上传参可能被截断为 32 位，尤其跨 ABI（如 ARM64 传参寄存器 vs x86_64 栈传递） - 某层函数用
unsigned short接收长度 → 超过 65535 直接回绕，静默错误 - 调用前做
len = std::min(len, MAX_ALLOWED)，但没检查len == 0导致空指针解引用（某些编译器不认为ptr + 0是未定义行为，但ptr[0]是）
真正难的从来不是怎么传得快，而是怎么让每一层都清楚自己拿到的 len 是谁负责校验、谁负责截断、谁保证非零。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
