go语言读取音视频文件头部应避免os.readfile全量加载，须用os.open+io.readfull读前12字节，依格式魔术字节（如wav的"riff"、flv的"flv\x01"、mp4的ftyp box）解析，并校验wav的format.tag、flv的flags及mp4的box遍历以确保准确识别。
Go 语言读取音视频文件头部，核心就一条：别用 os.ReadFile 全量加载，直接打开 + 读前 N 字节 + 按规范解析。WAV、FLV、MP4、AVI 各自的“魔术字节”位置和长度不同，硬写通用逻辑反而容易错。
怎么安全读取前 12 字节判断格式
多数音视频格式靠开头固定字节（magic bytes）识别，比如 WAV 是 []byte{'R', 'I', 'F', 'F'}，FLV 是 []byte{'F', 'L', 'V', 0x01}，MP4 是 []byte{0x00, 0x00, 0x00, 0x18, 0x66, 0x74, 0x79, 0x70}（ftyp box）。读太少会撞上歧义，读太多浪费——12 字节够覆盖常见头部结构。
- 用
os.Open打开文件，立刻defer f.Close() - 分配
make([]byte, 12)，用io.ReadFull(f, buf)读满；若返回io.ErrUnexpectedEOF，说明文件太短，可直接判为非法 - 不要用
bufio.Scanner，它默认按行切分，对二进制头部无意义 - Windows 下注意路径编码，
filepath.FromSlash转换斜杠，避免\被误解析
WAV 文件头解析必须检查 Format.Tag
WAV 不是只看 RIFF 四字节就完事。真正决定能否用 github.com/eaburns/wav 解析的是 Format.Tag 字段，它在 chunk 数据偏移约 20 字节处（从 riff header 开始算）。很多工具导出的 WAV 实际是 ADPCM 或 IEEE Float，Tag != 1 就会触发 unsupported format 错误。
- 手动解析时，跳过 riff header（前 12 字节），再读 8 字节定位到 fmt chunk（含
fmt标识和 chunk size），然后读后续至少 16 字节获取Format.Tag、NumChannels等 - 用
eaburns/wav时，务必先wav.Decode再检查返回的Format.Tag，别假设一定是 PCM - 如果
Tag == 0xFFFE（即 WAVE_FORMAT_EXTENSIBLE），需额外读取SubFormatGUID 判断真实编码，该包不支持自动处理
FLV 文件头验证要读够 9 字节且检查 flags
FLV 头固定 9 字节：FLV\0x01 + flags + header size。其中 flags 第 8 位（0x04）表示含视频，第 6 位（0x01）表示含音频——很多解析器只校验前 4 字节，漏掉这个会把纯音频 FLV 当作无效文件。
- 读完 9 字节后，用
buf[4] & 0x04 != 0判断视频存在，buf[4] & 0x01 != 0判断音频存在 -
header size是大端 4 字节整数，在buf[5:9]，必须 >= 9，否则是损坏文件 - 别依赖
os.Stat获取文件大小来预判是否可读——有些网络流或管道返回 size 0，但头仍可读
MP4 / MOV 的 ftyp box 可能不在开头
MP4 规范允许 ftyp box 出现在文件任意位置（虽然实践中基本都在开头）。只读前 12 字节可能拿不到 ftyp，导致误判为非 MP4。真要可靠识别，得实现简易 box 遍历：读 8 字节（size + type），若 type == []byte{'f','t','y','p'}，则解析成功；否则跳过 size 字节继续读。
- box size 是大端 32 位整数，
binary.BigEndian.Uint32(buf[:4])解析 - size = 1 表示“扩展 size”，需再读 64 位整数，但实际 MP4 极少用，可先忽略
- 遍历时注意边界：若剩余字节数
- 对性能敏感场景（如 HTTP Range 请求头校验），可限定最多遍历前 64KB，避免扫描整个大文件
最易被忽略的一点：所有音视频头部解析都必须做字节序判断，不能默认小端或大端——WAV 用 little-endian，FLV/MP4 用 big-endian，混用会导致 SampleRate 或 header size 解析成荒谬数值。每次读多字节整数前，先确认格式规范再说。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
