wav文件采样率和通道数必须从fmt子块中读取：先跳过riff头和wave标识，定位fmt块（末尾带空格），再偏移8字节获取nchannels（2字节）、nsamplespersec（4字节）等字段，需逐字段读取并手动处理小端序，不可硬编码偏移或直接结构体读取。
WAV文件头结构决定了怎么读采样率和通道数
WAV是RIFF格式的子集，关键信息全在fmt 子块里——不是文件开头，也不是任意位置。必须跳过RIFF头和WAVE标识，定位到fmt chunk（注意末尾有个空格），再偏移8字节才能拿到wFormatTag、nChannels、nSamplesPerSec这三个字段。
常见错误是直接从文件起始读16字节就以为是格式信息，结果读到的是RIFF签名"RIFF....WAVE"，完全对不上。WAV头有可变长的LIST或JUNK块，不能硬编码偏移。
- 用
fread或std::ifstream::read逐块解析，每次读4字节chunk ID + 4字节size - 遇到
fmt就停，再读2字节wFormatTag（通常为1）、2字节nChannels、4字节nSamplesPerSec - Windows API的
WAVEFORMATEX结构体大小不固定（可能含扩展字段），但前16字节布局是标准的
用C++标准库安全读取，避开字节序和内存对齐陷阱
WAV是小端序，x86/ARM上直接reinterpret_cast可能出错，尤其当结构体被编译器填充时。最稳妥的方式是逐字段读取并手动转换字节序。
例如nSamplesPerSec是LE 32位整数，需用le32toh()（Linux）或_byteswap_ulong()（MSVC），而不是直接赋值给uint32_t变量。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 声明
uint16_t nChannels;后，用fread(&nChannels, 1, 2, fp)读，再调le16toh(nChannels) - 不要定义
struct WavHeader然后一次性fread——不同平台padding不同，字段会错位 - 如果用
std::ifstream，务必设ios::binary，否则Windows下遇到0x0D 0x0A会被转成单个\n
遇到fmt 块长度大于16怎么办
标准PCM格式的fmt 块长度是16，但扩展格式（如IEEE Float、多声道）会写成18或40，多出的字段包括wValidBitsPerSample、dwChannelMask等。如果只关心采样率和通道数，前16字节足够；但若cbSize（即fmt 块第16–17字节）非零，说明后面还有数据，需按长度跳过，否则会影响后续data块定位。
- 读完前16字节后，再读2字节
cbSize，用le16toh()转成实际扩展长度 - 接着
fseek(fp, cbSize, SEEK_CUR)跳过扩展区，才能准确定位到data块 - 忽略
cbSize直接往后读，可能导致把扩展字段当data起始，解析出错
实操中容易漏掉的边界情况
不是所有.WAV文件都合规：有的缺fmt 块，有的data块在前，有的用RF64替代RIFF（64位长度）。生产环境必须做校验，不能假设文件一定正确。
- 检查RIFF signature是否为
"RIFF"，WAVE type是否为"WAVE"，否则不是合法WAV - 遍历chunk时，若遇到未知ID且size很大（比如超10MB），应中断解析，防止OOM
- 采样率字段为0是非法值，但有些损坏文件会这样，需显式判断并报错
- 用
std::ifstream::gcount()确认每次read()是否读满预期字节数，避免EOF提前导致字段错乱
真正麻烦的从来不是读两个字段，而是处理那些“本不该存在却真实出现”的畸形文件头。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
