Nginx 的 mime.types 文件需通过 include 显式引入才生效，仅靠文件扩展名匹配哈希表生成 Content-Type 响应头；未匹配且无 default_type 时则不发送该头；后定义的 types 优先级更高。
Nginx 的 mime.types 文件本身不自动生效，它只是一个静态映射表，必须被主配置显式引入（include），才能参与响应头生成。
它起作用的方式很直接：Nginx 在处理静态文件请求时，只看 URL 路径末尾的扩展名（比如 /app.js → 提取 js），然后在内存中查一张由所有 types 块合并构建的哈希表——这张表的源头就包括默认 mime.types 和你自定义的 types 块。匹配成功后，就把对应 MIME 类型写进 Content-Type 响应头；没匹配上，又没设 default_type，那这个头干脆就不发。
它依赖 include 才能加载
`mime.types` 是纯配置片段，不是可执行模块。Nginx 启动时不会自动读它，必须在 `http { }` 块里写： ```nginx include mime.types; ``` 这行通常放在 `default_type` 之前或之后都行，但要确保在 `http` 作用域内。路径默认是相对 `nginx.conf` 所在目录的，常见位置有： - `/etc/nginx/mime.types` - `/usr/share/nginx/mime.types` - 编译安装路径下的 `conf/mime.types`它不分析文件内容，只靠后缀字符串匹配
Nginx 不打开文件、不读字节流、不验证 Magic Number。 比如请求 `/icon.avif`，它只截取 `avif`，然后查表找有没有 `image/avif avif;` 这样的行。 哪怕你把一个 `.jpg` 文件改成 `.avif` 后缀，Nginx 也会返回 `Content-Type: image/avif` —— 浏览器信不信，那是另一回事。它会被后续 types 块覆盖
同一扩展名如果在多个 `types` 块里出现，**后定义的生效**。所以推荐写法是： ```nginx http { include mime.types; # 先加载官方默认表 types { # 再追加或修正 application/javascript mjs; font/woff2 woff2; image/avif avif; } default_type application/octet-stream; } ``` 这样 `.mjs` 就会用 `application/javascript`，而不是默认的 `application/octet-stream` 或旧版可能配的 `text/plain`。它和 default_type 是搭档关系
`mime.types` 只管“已知类型”，不管“未知类型”。 如果请求 `/data.asset`，而所有 `types` 块里都没写 `asset`，Nginx 就不会发 `Content-Type` 头——除非你设置了： ```nginx default_type application/octet-stream; ``` 这个兜底值决定了浏览器对未识别资源的行为：设成 `application/octet-stream` 会强制下载；设成 `text/plain` 可能让日志文件直接在浏览器里打开，但也可能让二进制资源被错误解析。不复杂但容易忽略
