直接读文件头比对魔数最可靠，binary.read因按端序解析整数会破坏魔数字节顺序，且不保证读满、无法跳过非魔数字段；应使用io.readfull读取固定长度字节切片后用bytes.equal比对。
直接读文件头比对魔数是最可靠的方式，binary.Read 不适合做格式识别——它会把字节当数值解析，破坏原始魔数含义。
为什么不能用 binary.Read 读文件头
binary.Read 的设计目标是解码端序敏感的整数类型（如 uint32），而文件魔数是固定字节序列，不表示数值。比如 PNG 开头 0x89 0x50 0x4E 0x47，若用 binary.LittleEndian 读成 uint32，得到的是 0x474E5089，和原始字节顺序完全相反。
- 魔数匹配依赖字节原样一致，不是数值等价
-
binary.Read在读不满时静默失败或 panic，不如io.ReadFull明确返回io.ErrUnexpectedEOF - 它不处理偏移，无法跳过 header 中非魔数字段（如 ELF 的 e_ident 前 16 字节含魔数但后接版本/ABI 字段）
正确读取前 N 字节的姿势
分配固定长度切片 + io.ReadFull 是安全底线。它保证读满或明确报错，避免截断导致比对失效。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 用
head := make([]byte, 16)分配缓冲区，覆盖常见魔数长度（PNG/JPEG/GIF/ELF 等均 ≤16 字节） - 调用
io.ReadFull(file, head)，文件不足 16 字节时返回io.ErrUnexpectedEOF，可据此降级处理（如只比前 4 字节） - 比对必须用
bytes.Equal(head[:4], []byte{0x89, 0x50, 0x4E, 0x47})，禁止转字符串（UTF-8 编码会篡改二进制） - 别用
file.Read(head)或bufio.NewReader(file).Read(head)，它们不保证读满，易造成静默错配
http.DetectContentType 的适用边界
它仅对前 512 字节做硬编码比对，快但有硬伤：不读磁盘、不解析结构、不支持自定义规则，且对短输入或变体格式鲁棒性差。
- 传入
[]byte{0xff, 0xd8, 0xff}可能返回application/octet-stream，因 JPEG 签名需至少 3 字节且位置固定，而该函数内部匹配逻辑要求更长上下文 - 它不适用于可执行文件（PE/Mach-O/ELF）、PDF、Office 文档等——这些格式魔数分散或需解析字段，标准库未覆盖
- 想用于文件，必须先用
io.ReadFull读前 512 字节到buf，再调用http.DetectContentType(buf[:n])；别用os.ReadFile全量加载大文件 - 返回结果只是 MIME 类型提示，和文件真实内容无强约束，不能替代白名单校验
魔数比对的实际陷阱
看似简单的字节比较，实际容易在细节上翻车：扩展名伪造、大小写混淆、多版本魔数遗漏、权限与类型误判。
- 同一格式可能有多个魔数：BMP 有 16 色、24 位、256 色三种头部，需全部覆盖；TIFF 有 II（Intel）和 MM（Motorola）两种字节序前缀
-
mime.TypeByExtension完全不可信——evil.exe改名成report.pdf就能绕过，且默认不支持.avif等新格式 -
fi.IsDir()为 false 不代表是普通文件，还可能是 socket、device、symlink，真要区分得用fi.Mode() & os.ModeType位运算 - HTTP 上传时，
multipart.FileHeader.Header.Get("Content-Type")和前端 JS 设置的FormData.append类型都可被篡改，必须以文件头为准
魔数比对本身简单，但生产环境里最常出问题的不是逻辑，而是没检查 io.ReadFull 的错误、用了错误的字节序解读、或漏掉了某类文件的变体签名——这些地方一错，整个校验就形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
