靠扩展名查 MIME 快但不准，应先转小写并支持带/不带点输入，未命中返回 application/octet-stream；Windows 的 FindMimeFromData 有 COM 和 IO 风险，不推荐；高可靠性场景必须读文件头（如前 512 字节）配合 libmagic。
直接靠扩展名查 MIME 是危险的，但确实能快速 fallback
扩展名不是文件内容的权威标识，libmagic（如 file 命令）靠的是文件头字节，而扩展名只是约定俗成的提示。C++ 标准库不提供 MIME 推断能力，所有“仅靠扩展名映射”的方案本质都是查表——快、轻、不准，适合日志分析、缓存预判或前端响应头兜底。
用 std::unordered_map 手写扩展名到 MIME 的映射表最可控
别依赖第三方 MIME 库（比如 mime-types 的 C++ 绑定），它们往往过度设计，且默认行为可能自动 fallback 到 application/octet-stream 或触发 IO。自己维护一张小表，明确知道每个扩展对应什么，也方便按需增删。
常见错误现象：std::map 查扩展时忘了转小写，导致 .JPG 和 .jpg 匹配失败；或者没处理点号缺失的情况（如传入 "png" 而非 ".png"）。
- 统一把输入扩展转为小写后再查表
- 支持带点和不带点两种输入：先试
".ext，再试"ext" - 对空扩展、含路径的字符串（如
"/a/b/c.pdf"）提前用std::filesystem::path::extension()提取 - 未命中时返回
"application/octet-stream"，而非空字符串或抛异常——HTTP 协议要求有值
示例逻辑：
立即学习“C++免费学习笔记（深入）”；
std::string get_mime_from_ext(const std::string& ext) {
static const std::unordered_map<std::string, std::string> mime_map = {
{".txt", "text/plain"},
{".html", "text/html"},
{".jpg", "image/jpeg"},
{".png", "image/png"},
{".js", "application/javascript"},
{".json", "application/json"}
};
auto key = ext.empty() ? "" : (ext[0] == '.' ? ext : "." + ext);
std::string lower_key = key;
std::transform(lower_key.begin(), lower_key.end(), lower_key.begin(), ::tolower);
auto it = mime_map.find(lower_key);
return it != mime_map.end() ? it->second : "application/octet-stream";
}
Windows 上用 FindMimeFromData 会触发 COM 初始化和潜在 IO
这个 API 看似“不用打开文件”，但它内部可能读取前 256 字节做轻量检测，还会尝试加载注册表中关联的 MIME 处理器。实际测试中，对某些损坏或权限受限的路径，它会卡住或返回 INET_E_DEFAULT_ACTION。更麻烦的是，它要求调用方已初始化 COM（CoInitializeEx），在多线程或嵌入式场景里极易出错。
- 除非你已在使用 COM 且信任 Windows 注册表的 MIME 配置，否则别碰
FindMimeFromData - 它不接受纯扩展名输入，必须传入原始字节缓冲区（哪怕全填 0）和长度，徒增复杂度
- 返回的 MIME 字符串带换行符，需手动 trim
真正安全的 MIME 判定必须读文件头，但可以只读前几百字节
如果业务真需要准确类型（比如上传校验、内容分发），扩展名映射只能当第一层过滤，第二层必须 inspect 文件头。C++ 里最轻量的做法是用 std::ifstream 以 std::ios::binary 模式打开，read() 前 512 字节，再交给 libmagic 的 C API（magic_buffer）解析。
- 不要用
std::filesystem::file_size()判断是否可读——它不检查权限，也不代表能 open - open 失败时立即返回 fallback MIME，别重试或抛异常
-
libmagic数据库需显式加载（magic_open(MAGIC_MIME_TYPE)），且应复用单例句柄，避免反复编译 magic 数据库的开销 - 注意
magic_buffer返回的字符串结尾带"\n"，要erase掉
这一步绕不开系统调用，但“只读头”已极大降低性能影响——比全量扫描快两个数量级，也比依赖扩展名可靠得多。
真正难的不是选函数，而是想清楚：你的场景到底能容忍多少误判？如果只是生成静态资源响应头，查表够用；如果涉及用户上传文件的执行策略，那不读头就是留后门。
