Go http.DetectContentType 怎样判断上传文件类型

Go 处理文件上传时，判断类型的关键不是文件名后缀，而是文件内容的开头字节。http.DetectContentType 会按 MIME Sniffing 规则检查传入数据，最多使用前 512 字节；如果无法判断更具体的类型，就返回 application/octet-stream。所以它适合做“内容类型线索”，后面仍应接大小、业务格式和存储策略。

官方资料：https://pkg.go.dev/net/http#DetectContentType

先分清要判断的是内容还是上传元数据

一个 multipart 上传通常同时带着三种信息：文件名、客户端声明的 Content-Type，以及文件 Part 的真实字节。它们不是同一件事。

如果题目是“上传图片是否允许”，建议至少把内容探测结果和业务允许列表放在同一个决策点；如果题目只是“响应头应该写什么”，也可以把检测结果作为响应的 Content-Type 候选，但不要把它误认为完整的文件格式解析。

读取前 512 字节，同时保留后续完整流

直接读取头部会改变 Reader 的当前位置。后面若还要保存文件，必须把已经读过的字节重新接回去。下面的函数返回两个结果：检测出的 MIME 类型，以及从文件开头重新开始的 Reader。

package main

import (
    "bytes"
    "fmt"
    "io"
    "net/http"
)

func sniffAndReplay(src io.Reader) (string, io.Reader, error) {
    head := make([]byte, 512)
    n, err := io.ReadFull(src, head)
    if err != nil && err != io.EOF && err != io.ErrUnexpectedEOF {
        return "", nil, err
    }
    if n == 0 {
        return "", nil, fmt.Errorf("文件为空")
    }

    // 只把实际读到的字节交给探测函数，短文件也能正常处理。
    kind := http.DetectContentType(head[:n])

    // 把已读头部放回流的最前面，保存时不会丢失这部分内容。
    replay := io.MultiReader(bytes.NewReader(head[:n]), src)
    return kind, replay, nil
}

io.ReadFull 对短于 512 字节的文件会返回 io.ErrUnexpectedEOF，但 n 仍然是已经读到的字节数，因此不能把这个错误一律当成失败。只有空文件没有可供判断的字节；未知类型则由 DetectContentType 返回通用 MIME 类型。

在 multipart 的文件 Part 上检测，不要检测整个请求体

当请求是 multipart/form-data 时，整个 r.Body 还包含 boundary、字段名和其他表单字段。真正应该交给 DetectContentType 的对象是文件 Part，也就是 r.FormFile("file") 返回的文件流。

func uploadHandler(w http.ResponseWriter, r *http.Request) {
    // 先限制请求总量，避免无界上传占用内存和磁盘。
    r.Body = http.MaxBytesReader(w, r.Body, 32

示例中的 header.Filename 只用于返回展示；真正的存储名仍应由服务端生成。io.Copy 使用的是回放后的 Reader，所以检测头部不会导致保存结果缺少文件开头。

把检测结果接入允许类型判断

比较稳妥的决策顺序是：先限制请求大小，再取得文件 Part，读取有限窗口，得到 MIME 类型，最后与服务端允许列表比较。文件名后缀可以用于生成展示名，客户端 Content-Type 可以写入日志，但两者都不应覆盖内容探测结果。

需要注意，MIME 类型判断并不等于完整格式校验。例如返回 image/png，只说明开头字节符合 PNG 的识别规则；如果业务还要求图片尺寸、PDF 页数或文件内容可解析，就应该继续调用相应解析器，并把解析失败作为独立分支。

空文件、未知类型和短文件怎么处理

此外，探测窗口最多是 512 字节，不等于服务端可以无限读取请求。上传总量限制、临时文件清理、存储路径生成和业务格式解析仍然需要各自负责。

一套可复用的排查顺序

1. 确认拿到的是文件 Part，而不是整个 multipart 请求体。
2. 确认只读取有限的前缀，并处理空文件和短文件。
3. 确认已经读过的前缀通过 io.MultiReader 回放给后续保存逻辑。
4. 确认允许列表使用服务端检测结果，文件名和客户端头部只作辅助。
5. 确认未知 MIME 类型仍会进入明确的业务分支，而不是悄悄绕过限制。

常见问题：

• 为什么不能只看扩展名？扩展名来自名称元数据，容易被改写，不能代表文件内容。
• 为什么检测后保存文件变小了？通常是头部已经被 Reader 消费，保存时没有把已读字节放回去。
• application/octet-stream 一定是坏文件吗？不一定，它表示标准库没有识别出更具体的 MIME 类型，是否允许应由业务规则决定。