解析wav文件必须先跳过riff头和fmt子块定位到"data"chunk起始处，严格按waveformatex顺序读字段，校验wformattag，处理字节序与对齐，按声道拆分交错数据，并遍历所有chunk而非假设顺序。
WAV 文件头解析不校验直接读数据，必崩
WAV 是 RIFF 容器格式，不是纯 PCM；fread 从文件开头硬读音频样本，大概率读到的是 riff 头或 fmt 子块，导致数据错位、静音或崩溃。必须先跳过合法头结构，定位到 "data" chunk 起始位置。
实操建议：
- 用
fread读前 12 字节，检查是否为"RIFF....WAVE"（注意字节序和 padding） - 读取
fmt子块长度（4 字节），再跳过该长度，直到遇到"data"标识符 - 紧接着的 4 字节是采样数据总字节数，之后才是真正的
int16_t或float32样本 - 别信文件扩展名——有些 .wav 实际是 IEEE float 格式，
wFormatTag字段必须检查，常见值：0x0001（PCM）、0x0003（IEEE float）
用 std::ifstream 读二进制 WAV，seekg 容易偏移错
WAV 的 chunk 对齐要求是 2 字节边界，但 fmt 块末尾可能有 pad byte；如果只按字段长度累加偏移，seekg 会落在 "data" 标识符中间，后续读出全乱码。
实操建议：
- 每次读完一个 chunk 后，用
file.tellg()记录当前位置，再读 chunk size，计算下一个 chunk 起始 = 当前位置 + 8（chunk header 长度）+ size - 读
fmt块时，先读 2 字节wFormatTag，再读 2 字节nChannels，再读 4 字节nSamplesPerSec……严格按WAVEFORMATEX定义顺序，别靠 sizeof(struct) - 遇到未知 chunk 类型（比如
"LIST"或"fact"），按 size 跳过，别假设只有"fmt "和"data"
std::vector<int16_t></int16_t> 存 PCM 数据，但声道交错没拆开
绝大多数 WAV 是 interleaved：左声道第 0 样本、右声道第 0 样本、左声道第 1 样本……连续存放。如果直接把整块数据当单声道处理，做 FFT 或滤波就会出错。
实操建议：
- 读完
datachunk 后，根据nChannels和wBitsPerSample算出每帧字节数：bytes_per_frame = (wBitsPerSample / 8) * nChannels - 用
std::vector<:vector>></:vector>按声道拆分：对每个样本索引i，左声道取data[i * nChannels + 0]，右声道取data[i * nChannels + 1] - 如果后续要做卷积或重采样，提前拆成单声道向量更安全；临时需要 interleave 再合并，别反复来回转换
- 注意：
wBitsPerSample == 24时，不能直接reinterpret_cast<int16_t></int16_t>，得手动提取 3 字节转int32_t再归一化
跨平台读 WAV 时，short 大小和字节序不一致
Windows 上 short 是 2 字节，Linux/macOS 也是，但某些嵌入式工具链或旧编译器可能不同；更关键的是 WAV 标准规定所有整数字段为 little-endian，而你的 CPU 可能是 big-endian（比如部分 ARM 设备）。
实操建议：
- 所有从文件读出的多字节整数（
uint32_t,uint16_t），必须用le16toh()/le32toh()转换（POSIX）或手写翻转逻辑 - 别依赖
sizeof(short) == 2，显式用int16_t和uint32_t，并确认头文件包含<cstdint></cstdint> - 测试时找一个已知参数的 WAV（如 44.1kHz / 16-bit / stereo），用
ffprobe -v quiet -show_entries stream=sample_rate,channels,bits_per_sample test.wav对照验证
事情说清了就结束。最常被忽略的是：WAV 不保证只有一个 "data" chunk，也不保证 "fmt " 在 "data" 前面——虽然几乎总是这样，但生产环境必须按规范遍历 chunk 链。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
