http.DetectContentType仅检测前512字节，非万能：它纯内存比对、不读磁盘、不解析完整结构，对截断/加密/格式异常文件易误判，且不适用于可执行文件、归档包等复杂格式校验。
http.DetectContentType 只能检测前 512 字节，不是万能的
http.DetectContentType 是 Go 标准库提供的轻量级 MIME 探测函数，但它只读取输入的前 []byte 的头 512 字节，不做文件系统访问、不读磁盘、不解析完整文件结构。这意味着：如果文件头部被截断、加密、压缩或格式不规范（比如 PNG 文件开头被加了自定义 header），结果大概率不准。
常见错误现象：http.DetectContentType([]byte{0x89, 0x50, 0x4e, 0x47}) 返回 "image/png" 没问题，但 http.DetectContentType([]byte{0xff, 0xd8, 0xff})（JPEG 开头）可能返回 "application/octet-stream" —— 因为传入的字节太少，没凑够 JPEG 签名所需的最小长度（通常要 3–10 字节且位置固定）。
- 使用场景：适合 HTTP 上传时快速初筛表单字段中的小文件（如头像、图标），或做 fallback 判断
- 不要用于校验用户上传的可执行文件、归档包（zip/tar）、PDF 或 Office 文档——它们的 magic bytes 分布复杂，且常被混淆
- 参数差异：它只接受
[]byte，不接受*os.File或路径；想用文件得先io.ReadFull读前 512 字节到 buffer - 性能影响：极低，纯内存比对；但别把它当“安全校验”用，MIME 类型和实际内容完全无关
读文件前 512 字节的正确姿势：别用 ioutil.ReadFile
直接 ioutil.ReadFile（或 os.ReadFile）整个文件再切片，对大文件是典型资源浪费，还可能 OOM。正确做法是打开文件、io.ReadFull 读固定长度，再关闭。
示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
file, _ := os.Open("upload.zip")
defer file.Close()
buf := make([]byte, 512)
n, _ := io.ReadFull(file, buf)
if n < 512 && !errors.Is(err, io.EOF) {
// 实际读不满 512 字节（比如文件小于 512B），也 OK，DetectContentType 能处理
}
mime := http.DetectContentType(buf[:n])
- 容易踩的坑：
io.ReadFull在文件不足 512 字节时会返回io.ErrUnexpectedEOF，不是io.EOF；要用errors.Is(err, io.ErrUnexpectedEOF)判断，或直接忽略 err（因为buf[:n]已有效） - 别用
file.Read(buf)替代io.ReadFull：它可能只读几字节就返回，导致探测失败 - 兼容性注意：Go 1.16+
os.ReadFile默认限制 100MB，但依然不适用于大文件 MIME 探测
为什么不能只信 Content-Type 请求头
客户端发来的 Content-Type 请求头（比如 multipart 表单里的 Content-Type: image/gif）完全由浏览器或调用方填写，毫无可信度。攻击者可以轻易伪造为 text/plain 绕过后端图片校验，再上传含恶意 PHP 代码的“图片”。
- 真实场景：你允许用户上传头像，前端 JS 检查了
file.type是"image/jpeg"，后端却只校验请求头——等于裸奔 - 必须组合使用：先用
http.DetectContentType做初步识别，再结合扩展名白名单（如只允许.jpg、.png）、甚至调用外部工具（file命令）做二次验证 - 性能权衡：纯 Go 的 magic 检测快但覆盖有限；
github.com/gabriel-vasile/mimetype这类第三方库支持更多格式，但引入额外依赖
detectContentType 对 ZIP/PDF/JSON 的识别边界在哪
http.DetectContentType 内置规则极少：只覆盖 HTML、XML、JSON、PNG、GIF、JPEG、WebP、SVG 等约 10 种常见类型，且依赖严格签名。它不识别 ZIP（PK\x03\x04）、PDF（%PDF-）、DOCX（ZIP 容器）、YAML（无明确 magic）、MP4（ftyp box）等。
- 典型失败案例：
http.DetectContentType([]byte("%PDF-1.7"))返回"application/octet-stream"；http.DetectContentType([]byte("PK\x03\x04"))同样失败 - 如果你的业务真要支持这些格式，要么换库（如
mimetype），要么自己写简单 magic 匹配（例如检查前 10 字节是否含"%PDF-"） - 注意 PDF 的签名可能出现在第 1–4KB 内（比如有 BOM 或注释），只读前 512 字节仍可能漏判
真正难的从来不是调用 http.DetectContentType 这一行代码，而是想清楚你要防御什么、能接受多大误报率、以及当它返回 "application/octet-stream" 时，你的 fallback 逻辑是什么。
