mime包仅处理扩展名映射、媒体类型字符串解析/组装及自定义类型注册，不检测文件内容；真正嗅探内容用http.DetectContentType，解析完整Content-Type头应使用net/http.ParseMediaType。
mime 包不是用来“解析 HTTP 请求头”或“识别文件真实类型”的万能工具——它只做三件事：查扩展名映射、拆解/组装带参数的媒体类型字符串、注册自定义类型。真正负责内容嗅探的是 http.DetectContentType，而解析完整 Content-Type 头（含 charset、boundary 等）该用 net/http.ParseMediaType。
用 mime.TypeByExtension 查扩展名 → MIME 类型？小心 fallback 到 text/plain
这个函数只查内置映射表，不读文件、不验证内容。传入 ".xls" 返回空字符串，传入 ".png" 才返回 "image/png"。常见陷阱包括：
- 扩展名大小写不敏感但函数要求小写带点，
mime.TypeByExtension("PNG")返回空，必须用".png" - 复合扩展名如
".tar.gz"会被filepath.Ext截成".gz"，结果得到"application/gzip"而非预期的"application/x-tar" - Windows 可执行文件
".exe"默认映射为"application/octet-stream"，不是"application/x-msdownload"—— 需手动mime.AddExtensionType(".exe", "application/x-msdownload")
用 mime.ParseMediaType 解析 Content-Type 字符串？别漏掉 net/http
mime.ParseMediaType 确实能拆开 "text/html; charset=utf-8; version=1"，但它不处理 RFC 7231 定义的 quoted-string、注释、空格归一化等细节。实际项目中应优先用 net/http.ParseMediaType，它内部调用 mime 但补全了语义：
-
mime.ParseMediaType("text/plain; charset=\"utf-8\"")会把charset值解析成"\"utf-8\""（带引号），而http.ParseMediaType正确返回"utf-8" - 遇到非法格式（如缺失分号、乱序参数）时，
http.ParseMediaType有更健壮的容错逻辑 - 标准库文档明确建议：HTTP 场景统一走
net/http，mime仅用于底层 MIME 字符串构造/匹配
为什么 http.ServeFile 总返回 text/plain？和 mime 的 fallback 机制直接相关
http.ServeFile 内部调用 mime.TypeByExtension(filepath.Ext(path))，一旦扩展名未注册或为空（比如 "report" 或 "data."），就硬编码 fallback 到 "text/plain; charset=utf-8"。这不是 bug，是设计选择：
- 不主动 panic 或 error，而是保底输出可读文本 —— 对调试友好，但对生产下载极不友好
- 解决方法不是改
mime表，而是绕过它：w.Header().Set("Content-Type", "application/vnd.ms-excel")必须在http.ServeFile前设置 - 若文件来自数据库或内存流（无路径），
mime.TypeByExtension完全失效，此时只能靠客户端声明的原始类型或http.DetectContentType（注意：仅读前 512 字节）
mime 是个轻量、确定性高的字符串工具，不是类型检测引擎。它的价值在于快、无依赖、可预测；代价是完全不感知内容。混淆它和 http.DetectContentType 或 net/http.ParseMediaType，是 Go 新手最常踩的类型判断类坑。 
