mimetype包与file命令结果不一致，因其仅检测前512字节magic bytes，不解析内容、不解压、不依赖扩展名，也不支持Office/PDF等深度规则；而file命令综合扩展名、嵌套检测及编码识别。
为什么 mimetype 包识别结果和 file 命令不一致？
因为 mimetype 包只看文件头部（magic bytes），不读取扩展名，也不做内容解析或解压；而系统 file 命令会结合扩展名、多层嵌套检测（比如 ZIP 里的 PNG）、甚至尝试解码文本编码。常见现象是：一个 .xlsx 文件用 mimetype.Detect 返回 application/zip，而不是 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet。
- 它只支持标准 MIME magic database（类似 libmagic 的简化版），没内置 Office、PDF 等复杂格式的深度规则
- 如果你依赖扩展名 fallback，得自己加逻辑：
if mime == "application/octet-stream" && strings.HasSuffix(name, ".pdf") { return "application/pdf" } - 对加密 ZIP、损坏头部、base64 编码体等场景直接失效，不会报错，只会返回通用类型
mimetype.Detect 的输入长度限制是多少？
默认只读前 512 字节 —— 这是硬编码值，在 mimetype 包源码里写死的。很多格式（如某些 PDF、FLAC、AVIF）的 magic signature 出现在 512 字节之后，导致误判为 application/octet-stream。
- 无法通过参数调整长度，必须自己截取或重写检测逻辑
- 安全起见，别传整个大文件（比如 100MB 视频）进去，它会 copy 前 512 字节，但调用方仍要承担读取开销
- 若需更高精度，建议用
io.LimitReader(f, 4096)配合自定义 magic 表，或换用gabriel-vasile/mimetype（支持可配长度和更多格式）
如何处理 multipart/form-data 上传中的文件类型检测？
HTTP 上传时，req.FormFile 返回的 *multipart.FileHeader 有 Header.Get("Content-Type")，但这只是客户端声明的值，不可信。必须用 mimetype.Detect 实际检测 body 数据。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别直接信任
fileHeader.Header.Get("Content-Type")，浏览器可能伪造，curl 可能完全不设 - 正确做法：先
src, _ := fileHeader.Open()，再buf := make([]byte, 512)+io.ReadFull(src, buf)，然后mimetype.Detect(buf) - 注意
io.ReadFull可能返回io.ErrUnexpectedEOF（文件小于 512 字节），此时应降级用mimetype.Detect(buf[:n]) - 检测完别忘了
src.Close()，否则文件句柄泄漏
替换 golang.org/x/net/html 以外的 MIME 检测方案？
标准库没有 MIME 检测能力，mimetype 是第三方包（通常指 github.com/gabriel-vasile/mimetype），不是 Go 官方包。很多人搜 “golang mimetype” 会误以为它是内置的，结果 go get golang.org/x/net/html 白忙一场。
立即学习“go语言免费学习笔记（深入）”；
- 确认导入路径是
github.com/gabriel-vasile/mimetype，不是mimetype或mime - 它的
mimetype.Lookup支持扩展名查表，mimetype.Detect支持 magic 检测，两个函数行为完全不同，别混用 - 如果项目已用
net/http.DetectContentType，注意它只适用于 HTML/XML/JSON 等文本类，对二进制文件基本无效
真正难的不是调用函数，而是判断什么时候该信扩展名、什么时候必须读 magic、以及当两者冲突时以哪个为准 —— 这取决于你的业务场景：上传头像可以宽松，解析用户提交的合同 PDF 就不能妥协。
