nginx mime 类型匹配基于单次哈希查表，仅取 uri 末尾扩展名查找首个匹配项，未命中则依赖 default_type；配置中重复定义同一后缀时，后加载的 types 块会覆盖前者，正则 location 不自动继承外层 types，需显式声明或 include，新增格式如 .mjs、.woff2、.avif 等须手动补全，拼写错误将导致完全不匹配。
Nginx 处理静态资源时，MIME 类型匹配本身不会发生“冲突”——它不支持多规则叠加或优先级判断，而是严格按哈希表单次查表：只取 URI 末尾扩展名（如 .js），在所有已加载的 types 块中找第一个匹配项，命中即返回对应类型，未命中则看 default_type。所谓“匹配冲突”，实际是配置叠加逻辑不清、作用域覆盖不当或后缀定义重复导致的意料外覆盖或遗漏。
避免 types 块相互覆盖
Nginx 启动时会把所有 types { } 块合并成一张哈希表。如果多个块都定义了同一个后缀，后出现的定义会覆盖前面的（按配置加载顺序）。例如：
- 在
/etc/nginx/mime.types中有：application/javascript js; - 又在
/etc/nginx/conf.d/custom.mime中写了：text/plain js; - 且
include /etc/nginx/conf.d/custom.mime;放在include mime.types;之后 → 最终.js会被识别为text/plain，脚本执行失败
✅ 正确做法：自定义文件只补全缺失类型，不重复定义已有后缀；如需覆盖，确保 include 顺序明确，并在注释中说明原因。
location 块内 types 丢失问题
当使用正则 location（如 location ~* \.(js|css|png)$）时，Nginx 不会自动继承外层 http 或 server 块中的 types 定义。若该 location 内没显式声明 types 或 include，就可能退回到 default_type，造成 MIME 错误。
- ❌ 错误示例：
location ~* \.js$ { root /var/www; }—— 没 types，也没继承机制 - ✅ 正确写法一（继承全局）：
location ~* \.js$ { root /var/www; types { application/javascript js; } } - ✅ 正确写法二（复用外部）：
location ~* \.js$ { root /var/www; include /etc/nginx/conf.d/custom.mime; }
扩展名歧义与常见陷阱
某些后缀易被误判，不是因为“冲突”，而是配置疏漏：
-
.mjs和.js需分别定义：application/javascript js mjs;或分开写两行，否则 ES 模块加载失败 -
.woff2不在旧版mime.types中，漏配会导致字体下载但不渲染 -
.webp、.avif等新图片格式同理，必须显式添加 - 拼写错误（如
woff2写成wof2）会导致完全不匹配，响应头缺失Content-Type
验证是否真正生效
改完配置不能只看 nginx -t 通过，必须实测响应头：
- 执行
nginx -s reload重载 - 用
curl -I https://yoursite.com/test.js查Content-Type是否为application/javascript - 对每个新增后缀单独测试：
curl -I /style.css、curl -I /icon.avif、curl -I /data.json - 若返回
text/html，大概率是路径 404 后 fallback 到 index.html，而非 MIME 配置问题
