http.DetectContentType常返回text/plain，因其仅检测前512字节的magic number，小文件、base64解码数据、截断图片或非标准格式均易匹配失败；应确保输入足长、避免解码后检测、谨慎处理multipart流，并优先以服务端字节检测结果为准，而非客户端Content-Type。
为什么 http.DetectContentType 经常返回 text/plain？
它只看前 512 字节，且不依赖文件扩展名或后端存储信息，纯靠字节模式匹配。遇到小文件、压缩包、加密内容、或头部被截断的图片（比如 base64 解码后直接传入），就大概率 fallback 到 text/plain。
常见错误现象：http.DetectContentType([]byte{0x89, 0x50, 0x4e, 0x47}) 能正确返回 image/png，但 http.DetectContentType([]byte("PNG")) 就不行——因为 PNG 真实签名是 8 字节，少一个字节就匹配失败。
- 确保输入至少有 512 字节；不足时手动补零或截取前 N 字节（N ≥ 512）再检测
- 不要对已解码的 base64 数据直接检测——base64 字符串本身是 ASCII，必然被识别为
text/plain - 避免对 HTTP body 流（如
req.Body）未读完就调用，否则可能只读到开头几字节
怎么安全地从 multipart.FileHeader 提取原始字节做检测？
Go 的 multipart.FileHeader 本身不提供文件内容，必须先用 Open() 打开，再读取前段字节。但直接 file.Read(buf) 会移动文件指针，后续上传逻辑可能读不到完整数据。
使用场景：接收用户上传的头像、文档，需在保存前校验 MIME 类型是否合法（比如只允许 image/jpeg 或 application/pdf）。
立即学习“go语言免费学习笔记（深入）”；
- 用
file.Open()得到multipart.File，再用io.ReadFull读取前 512 字节到buf := make([]byte, 512) - 读完后记得
file.Close()，并用bytes.NewReader(buf)或重新Open()进行后续处理 - 若文件小于 512 字节，
io.ReadFull会返回io.ErrUnexpectedEOF，此时应改用io.ReadAtLeast(file, buf[:n], n)动态适配长度
http.DetectContentType 和第三方库（如 gabriel-vasile/mimetype）差在哪？
标准库只实现最基础的 magic number 检测（PNG/JPEG/GIF/ZIP/TAR/UTF-8 BOM 等约 20 种），不支持 WebP、AVIF、DOCX、HEIC、甚至部分 PDF 变体。而 mimetype 库覆盖 300+ 类型，还支持扩展名 fallback 和深度嵌套检测（比如 ZIP 内部的 .xlsx）。
性能影响很小——两者都是内存内字节扫描，无 IO；兼容性上，http.DetectContentType 是标准库，无需引入依赖，适合轻量校验；但生产环境涉及文档、音视频、现代图像格式时，它基本不够用。
- 如果只要拦掉明显非法上传（比如把 .exe 改名成 .jpg），标准库够用
- 如果业务要精确区分
image/webp和image/avif，或验证 Office 文件结构，必须换库 - 注意：
mimetype.Detect默认也只读 512 字节，但提供DetectReader接口可传自定义 reader，更灵活
Content-Type 校验时，为什么不能只信客户端传来的 header.Get("Content-Type")？
那个字段完全由前端控制，可以伪造。比如 curl 发送 -H "Content-Type: image/jpeg"，但实际 body 是一段 shell 脚本——服务端若只检查 header 就直接存盘，等于开了个远程代码执行后门。
真实使用场景：用户通过表单上传头像，前端 JavaScript 用 File.type 设置了 image/png，但用户用开发者工具改了请求，或用非浏览器工具绕过前端校验。
- 永远以服务端实际读取的文件字节检测结果为准，忽略所有客户端声明的
Content-Type - 若检测出类型与业务预期不符（比如期望
image/*却得到application/x-executable），直接拒绝，不写磁盘、不进数据库 - 日志里记下原始 header 值和检测结果，便于追溯攻击尝试
