http.ServeFile 默认 Content-Type 为 text/plain 是因 mime.TypeByExtension 无法识别扩展名时 fallback 所致；应手动设置 Content-Type 和 Content-Disposition 响应头，且优先基于文件逻辑名（而非路径）推导类型，上传场景需持久化客户端声明的 original_mime。
用 http.ServeFile 直接下载文件时 Content-Type 总是 text/plain？
这是因为 http.ServeFile 会调用 http.ServeContent，而后者依赖 filepath.Ext 查扩展名来查 MIME 类型；如果扩展名不标准（比如 .xls 被识别为 .xlsx 的别名但未注册）、或文件无扩展名、或系统 mime.TypeByExtension 数据库缺失，就会 fallback 到 text/plain。
解决方法不是禁用自动类型推断，而是手动设置响应头：
func downloadHandler(w http.ResponseWriter, r *http.Request) {
filename := "report.xls"
filePath := "/path/to/report.xls"
// 强制指定 Content-Type，绕过 mime.TypeByExtension
w.Header().Set("Content-Type", "application/vnd.ms-excel")
w.Header().Set("Content-Disposition", `attachment; filename="`+filename+`"`)
http.ServeFile(w, r, filePath)
}
- 务必在
http.ServeFile前设置Content-Type和Content-Disposition -
Content-Disposition中的filename值需用双引号包裹，且内部双引号必须转义（Go 字符串中写成"\""） - 不要依赖
http.DetectContentType对整个文件做 sniff——它只读前 512 字节，对小文件可能误判，且无法覆盖ServeFile内部逻辑
需要流式传输大文件且动态生成 Content-Type？用 io.Copy + mime.TypeByExtension
当文件来自数据库 blob、加密解密后字节流、或临时生成（如 ZIP 打包），不能直接用 ServeFile，得自己控制响应体。这时 MIME 类型应基于**文件逻辑名**（用户看到的下载名），而非磁盘路径——因为流本身没有扩展名。
func streamDownloadHandler(w http.ResponseWriter, r *http.Request) {
fileName := "data.json" // 用户将看到的文件名
fileBody := getJSONStream() // io.ReadCloser，例如 gzip.NewReader(bytes.NewReader(data))
// 从 fileName 推导 Content-Type，不是从磁盘路径
contentType := mime.TypeByExtension(filepath.Ext(fileName))
if contentType == "" {
contentType = "application/octet-stream"
}
w.Header().Set("Content-Type", contentType)
w.Header().Set("Content-Disposition", `attachment; filename="`+fileName+`"`)
io.Copy(w, fileBody)
fileBody.Close()
}
-
mime.TypeByExtension只认常见后缀（.json,.pdf,.zip），对.tar.gz这类复合后缀返回空，此时应 fallback 到application/octet-stream - 若业务要求强一致性（如必须让浏览器用 Excel 打开
.csv），可硬编码：if strings.HasSuffix(fileName, ".csv") { contentType = "text/csv" } - 避免对大文件调用
io.ReadAll全部加载进内存——io.Copy是流式安全的
用户上传后原样下载，但 Content-Type 被浏览器篡改？
常见于前端用 上传，后端保存时没存原始 MIME，导致下载时只能靠扩展名猜——而用户可能把 image.jpg 改名为 photo.xyz 上传，后端再按 .xyz 查不到类型，最终返回 text/plain，浏览器就拒解析为图片。
立即学习“go语言免费学习笔记（深入）”；
根本解法：上传时记录客户端声明的 Content-Type，并持久化（如存在数据库字段 original_mime）：
func uploadHandler(w http.ResponseWriter, r *http.Request) {
r.ParseMultipartForm(32 << 20)
file, header, err := r.FormFile("file")
if err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
defer file.Close()
// 保存原始 MIME，而非靠 header.Filename 猜
savedPath := saveToFile(file, header.Filename)
storeInDB(savedPath, header.Header.Get("Content-Type")) // 记录原始值
}
下载时直接读取该字段：
w.Header().Set("Content-Type", dbRecord.OriginalMIME)
w.Header().Set("Content-Disposition", `attachment; filename="`+dbRecord.OriginalName+`"`)
http.ServeFile(w, r, dbRecord.LocalPath)
- 不要信任
header.Header.Get("Content-Type")绝对准确——某些旧浏览器或代理会丢弃或重写它，但相比扩展名，它仍是更可靠的信号 - 若存储层不支持额外字段，至少把
header.Header.Get("Content-Type")和filepath.Ext(header.Filename)都存下来，下载时优先用前者，为空再 fallback 到后者
Chrome 下载 .xlsx 文件打开提示“已损坏”，但文件实际可用？
这是 MIME 类型与文件实际二进制格式不匹配的典型表现。Excel 2007+（.xlsx）必须用 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet，若错设为 application/vnd.ms-excel（这是旧版 .xls 的类型），Chrome 会校验失败并报“已损坏”，尽管文件本身能被 Excel 正常打开。
正确做法是严格匹配扩展名与 RFC 标准 MIME：
-
.xls→application/vnd.ms-excel -
.xlsx→application/vnd.openxmlformats-officedocument.spreadsheetml.sheet -
.docx→application/vnd.openxmlformats-officedocument.wordprocessingml.document - 不确定时，查 IANA 官方注册表：https://www.iana.org/assignments/media-types
Go 标准库的 mime.TypeByExtension 对 .xlsx 默认返回空字符串，所以必须显式处理：
func getExcelContentType(ext string) string {
switch ext {
case ".xlsx":
return "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
case ".xls":
return "application/vnd.ms-excel"
default:
return mime.TypeByExtension(ext)
}
}
这类细节在开发阶段容易忽略，等 QA 或用户反馈才暴露——建议把常用办公文档的 MIME 映射做成常量表，在代码里集中维护。
