vector<int16_t> 比 vector<short> 更可靠，因 int16_t 明确为 16 位，而 short 大小不固定；用于序列化、网络传输或音频缓冲时必须用 int16_t，并注意内存连续性、对齐及指针生命周期。
vector 和 vector 有区别吗？
没本质区别，但 int16_t 更可靠。因为 short 只保证至少 16 位（C++ 标准），实际可能是 16/32 甚至更多位；而 int16_t 来自 <cstdint>，是明确的带符号 16 位整数——只要平台支持（几乎所有现代系统都支持）。如果你依赖“恰好 2 字节”做序列化、网络传输或内存对齐，必须用 int16_t。
常见错误现象：sizeof(short) 在某些嵌入式工具链里是 4，导致二进制协议解析错位；或者跨平台写文件时，Windows 编译器和 ARM GCC 对 short 的对齐策略不同，读取崩溃。
- 用
#include <cstdint>，声明为std::vector<int16_t> - 避免直接用
short做跨模块/跨平台数据交换 - 如果只是临时计算且不关心大小，
short可读性略高，但收益极小
push_back 一个大 short 数组会慢吗？
不会比 int 慢，但频繁单个 push_back 仍可能成为瓶颈——不是因为类型，而是因为动态扩容和拷贝开销。每个 short 占 2 字节，同样容量下，vector<short> 内存占用是 vector<int> 的一半，缓存友好性反而更好。
性能影响点：如果一次性要塞入 N 个值，别写循环调 N 次 push_back；改用 reserve + 迭代器插入，或直接构造：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::vector<int16_t> v; v.reserve(n); // 预分配，避免多次 realloc for (int i = 0; i < n; ++i) v.push_back(data[i]);
- 初始化已知大小？直接
std::vector<int16_t> v(n)或v(n, 0) - 从 C 数组复制？用
std::vector<int16_t> v(arr, arr + n) - 注意：
reserve不改变size()，只影响capacity()
vector 能直接 reinterpret_cast 成 int16_t* 吗？
能，但得确认两件事：一是 short 确实是 16 位且无 padding（用 static_assert(sizeof(short) == 2 && alignof(short) == 2) 守住）；二是你用的是标准布局类型（short 是）。更安全的做法是用 data()：
std::vector<int16_t> v = {1, 2, 3};
int16_t* ptr = v.data(); // ✅ 安全、标准、清晰容易踩的坑：
-
reinterpret_cast<int16_t*>(&v[0])在空 vector 时 UB（v[0]未定义） - 如果 vector 是
vector<short>，而你 cast 成int16_t*，虽通常可行，但标准不保证short和int16_t的 ABI 兼容（尤其在严格别名检查开启时，如-fstrict-aliasing） - 永远优先用
v.data()，它返回T*，类型干净，语义明确
用 vector 做音频缓冲区要注意什么？
常见场景：PCM 16-bit 音频样本（比如 WAV 文件、ALSA 输出）。这时核心是内存连续性、对齐、生命周期——不是类型本身。
关键点：
-
vector<int16_t>的数据一定是连续的（C++11 起保证），可直接传给write()、sf_writef_short()等 C API - 确保对齐：大多数音频驱动要求 16 字节对齐，而
vector默认使用std::allocator，不保证；如需严格对齐，得用自定义分配器或std::aligned_alloc+std::unique_ptr，vector不适合 - 别在回调中长期持有
data()指针：一旦 vectorresize或clear，指针失效 - 考虑用
std::span<const int16_t>（C++20）或gsl::span封装只读视图，避免意外修改
复杂点在于：你以为只是换了个类型，其实牵扯到 ABI、对齐、生命周期、C 接口契约——这些地方一松动，静音、爆音、崩溃就跟着来。
