nginx通过mime.types文件将文件后缀映射为content-type响应头，匹配基于uri末尾扩展名，启动时构建哈希表；直接修改默认mime.types有被覆盖、误操作和混淆风险，应使用include引入自定义types块，并配置default_type兜底，修改后需reload生效。
nginx 处理静态资源时，不看文件内容，只看后缀名，然后查 mime.types 文件决定返回什么 Content-Type 响应头。这个映射错了，浏览器就可能下错文件、不渲染样式、不执行脚本。
mime.types 的本质是后缀到 MIME 类型的查表规则
它不是程序逻辑，而是一组静态映射声明，语法简单：text/css css;image/png png;application/json json;
每行定义一种或多种扩展名对应一个 MIME 类型。Nginx 启动时加载整个文件，构建成哈希表供请求时快速匹配。
匹配过程严格基于 URI 路径末尾的扩展名（如 /style.css → css），不支持通配符、正则或路径层级判断。
为什么不能直接改系统自带的 mime.types 文件
直接编辑默认 mime.types（比如 /etc/nginx/mime.types）有三个实际风险：
- 升级 Nginx 时该文件可能被覆盖，导致自定义配置丢失
- 多人协作或自动化部署中，原文件易被误操作或脚本重置
- 无法清晰区分“官方默认”和“业务定制”，排查问题时容易混淆来源
推荐做法是：在 http 块中用 include 引入自己的类型文件，例如：include /etc/nginx/conf.d/custom.mime;
并在其中用 types { ... } 块内联定义，或完整复写所需映射。
没匹配上时的 fallback 行为很关键
如果请求的后缀（如 .webp 或 .mjs）在所有 types 块中都未定义，Nginx 就不会设置 Content-Type 头——除非你显式配置了 default_type。
常见配置是：default_type application/octet-stream;
这意味着未识别的文件会被当作二进制流下载，而不是尝试渲染。这对安全是合理的，但对新前端资源（如 .woff2、.avif）会导致字体不加载、图片不显示。
解决办法是补充对应映射，例如：
types {<br> application/font-woff2 woff2;<br> image/avif avif;<br>}
生效方式与调试要点
修改 mime.types 或其包含文件后，必须重载配置才能生效：nginx -s reload 或 systemctl reload nginx
验证是否生效，可直接用 curl 查响应头：curl -I https://example.com/test.js
重点检查返回中是否有 Content-Type: application/javascript（而非 text/plain 或缺失）。
注意：
– include mime.types; 必须出现在 http 块内，且通常在 default_type 之后；
– 多个 types 块按首次出现顺序合并，后定义的同扩展名不会覆盖前定义；
– 它与 sendfile、charset 等指令无依赖关系，各自独立作用。
