Go http.DetectContentType 只读取前 512 字节的判断边界

文件上传时，http.DetectContentType 不会把整个文件读一遍。它最多检查输入开头的 512 字节；输入不足 512 字节也可以参与判断，无法识别更具体类型时返回 application/octet-stream。因此它适合做低成本的 MIME 初判，不适合单独证明整个文件格式合法。

先把 512 字节理解成采样上限

官方文档对这个函数的描述很明确：算法最多考虑给定数据的前 512 字节。这里的关键是“最多”和“前面”。如果传入 4 KB，后 3584 字节不会让检测结果变得更全面；如果只传入 80 字节，函数也不会因为长度不足而拒绝工作。

这会影响两个常见判断。第一，返回 image/jpeg 只能说明采样内容符合识别算法的某种特征，不能代替 JPEG 解码器对完整文件的校验。第二，业务代码不应为了“凑够 512 字节”而无界读取上传体，否则采样函数前面的内存成本已经失去意义。

短输入和默认 MIME 类型要分开看

输入长度与识别结果是两件事。空切片、纯文本、格式不完整的片段，都可能进入同一个函数；长度本身不等于“合法”或“不合法”。当算法不能识别更具体的类型时，函数仍会返回一个有效的 MIME 类型，默认值是 application/octet-stream。

用受限读取封装流式初判

如果入口拿到的是 io.Reader，可以明确设置 512 字节上限。下面的函数只负责取样和返回类型，不把“检测通过”包装成安全结论；调用方还可以使用返回的采样长度记录诊断信息。

package main

import (
    "io"
    "net/http"
)

// sniffContentType 只读取最多 512 字节，避免把完整上传体装入内存。
func sniffContentType(r io.Reader) (string, int, error) {
    const sniffLimit = 512

    // LimitReader 把取样范围限制在函数契约内，短输入会自然读到 EOF。
    head, err := io.ReadAll(io.LimitReader(r, sniffLimit))
    if err != nil {
        return "", len(head), err
    }

    // 返回值可能是 application/octet-stream，表示未知而非读取失败。
    return http.DetectContentType(head), len(head), nil
}

这个封装有一个刻意保留的边界：它会消费 reader 的前 512 字节。如果后面还要把同一个流交给保存逻辑，就要在更上层使用可回放的缓冲、io.TeeReader 或重新组织读取顺序，不能假设检测函数会自动把字节放回去。读取错误仍然要返回给调用方，不能被默认 MIME 覆盖。

把检测结果放回业务校验链

上传接口可以把 DetectContentType 当成第一道低成本筛选：先限制请求体大小，再取前 512 字节做 MIME 初判；如果类型在允许集合内，再交给对应格式解析器做完整校验。扩展名和客户端传来的 Content-Type 可以作为辅助信息，但不要把它们单独当作文件事实。

一个实用的判断表如下：application/octet-stream 不应直接等同于拒绝，也不应直接等同于允许；它更适合进入“未知类型”的策略分支。对于必须确认格式的业务，应继续解析文件结构；对于只需要展示或转存的业务，也应保留大小、来源和失败原因。

常见问题

超过 512 字节的内容会被完整扫描吗？

不会。函数最多考虑前 512 字节，后续数据是否有效要由业务层或专用解析器决定。

返回 application/octet-stream 是函数报错吗？

不是。它是无法识别更具体类型时的正常返回值；真正的读取错误应由流读取操作单独报告。

读取不到 512 字节就一定不能检测吗？

不一定。短输入仍会尝试识别，但结果只代表已经提供给函数的那部分字节，不能扩大成完整文件校验结论。