合法WAV文件头必须前12字节为"RIFF"+4字节小端总长度+"WAVE"；需循环跳过非"fmt "/“data”块；fmt中须校验wFormatTag、nChannels等关键字段；data长度应与文件末尾对齐防越界。
WAV文件头结构怎么快速验证是否合法
直接读前12字节就能判断是不是有效WAV——"RIFF" + 4字节总长度 + "WAVE"，缺一不可。很多代码只校验"RIFF"就往下走，结果遇到损坏文件或非标准封装（比如某些录音笔导出的“伪WAV”）会崩在后续解析。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
fread一次性读12字节，检查buf[0..3] == "RIFF"、buf[8..11] == "WAVE"，别用strcmp直接比整个缓冲区 - 注意小端序：总长度字段
buf[4..7]要按uint32_t读，不能当字符串处理 - 如果
buf[4]是0xFF，大概率是无效长度，直接返回错误，别继续解析fmt块
怎么安全跳过非fmt和data的区块
WAV规范允许中间穿插LIST、INFO、fact等可选块，但很多C++示例代码硬编码假设fmt紧接RIFF之后，遇到带INFO块的文件就解析错位。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 从偏移12开始循环读取：每次读4字节块ID（如
"fmt "含空格）、再读4字节块长度 - 遇到
"fmt "就解析，遇到"data"就记录起始偏移和长度，其他块一律用fseek(fp, size, SEEK_CUR)跳过 - 块长度字段本身不包含头部8字节，但有些老工具写错了，导致长度偏小——读完后校验当前文件位置是否对齐到偶数字节，不对齐就
fseek(fp, 1, SEEK_CUR)补一位
fmt子块里哪些字段真会影响解码
不是所有fmt字段都要校验。比如wFormatTag为1（PCM）时，wBitsPerSample必须是8/16/24/32；但如果是3（IEEE float），wBitsPerSample就得是32，否则播放器可能静音或爆音。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必查：
wFormatTag、nChannels、nSamplesPerSec、nBlockAlign、wBitsPerSample - 可忽略：
cbSize（扩展字段长度）除非你真要支持ADPCM等编码 - 重点防坑：
nBlockAlign=nChannels * wBitsPerSample / 8，如果不等，说明文件异常——有些手机录音APP会填错这个值
为什么data块长度和文件实际大小对不上
常见于Windows生成的WAV：data块长度字段只计音频采样字节，不包括可能存在的填充字节（padding）或尾部冗余数据。更麻烦的是，有些设备会在data末尾多写几个零字节，导致fread读超界。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要依赖
data长度字段做内存分配上限，先用fseek(fp, 0, SEEK_END)拿到文件总长，再减去data块起始偏移，取二者最小值 - 读
data时用fread(buf, 1, min(expected_len, remaining_file_size), fp)，避免越界 - 如果
wBitsPerSample是24，务必按3字节/样本读，别用int16_t*强转——会错位且触发UB
最麻烦的是“双data块”文件：某些编辑软件导出时重复写了data标签，解析器得识别并只取第一个。这事没法靠规范保证，只能靠经验加白名单校验。
