直接在Nginx配置中用types块声明扩展名与MIME类型映射，配合default_type兜底，避免修改mime.types；需置于http或server块内、语法规范、顺序在include mime.types之后，配置后须nginx -t校验并reload生效。
直接在 Nginx 配置中声明扩展名与 MIME 类型的对应关系，而不是修改默认 mime.types 文件。核心是用 types 块定义映射，并配合 default_type 做兜底，配置完必须重载生效。
用 types 块补充或覆盖默认映射
Nginx 只看请求 URL 末尾的扩展名（比如 .js、.woff2），不读文件内容。它靠 types 块里的规则决定返回什么 Content-Type 头——这个头错了，浏览器就可能把 JS 当文本下载、把字体当乱码、把 JSON 渲染失败。
- 别直接改
/etc/nginx/mime.types：升级或重装容易被覆盖，协作时也难追踪 - 推荐做法是在
http或server块里内联写types，或者include自定义文件 - 内联示例（适合少量新增）：
types {<br> application/javascript js mjs;<br> font/woff2 woff2;<br> image/avif avif;<br> application/wasm wasm;<br>} - 分离写法（更清晰，推荐）：
新建/etc/nginx/conf.d/custom.mime，写入：types {<br> application/json json json5;<br> application/font-woff2 woff2;<br> image/webp webp;<br>}
再在nginx.conf的http块中加：include /etc/nginx/conf.d/custom.mime;
设置 default_type 兜底防止类型缺失
如果请求的后缀（如 .vitepress、.tsbuildinfo）没在任何 types 块里定义，Nginx 默认不设 Content-Type 头——浏览器就会按 text/plain 或 application/octet-stream 处理，现代前端资源大概率被拒绝。
- 显式配置
default_type是关键 - 安全兜底用：
default_type application/octet-stream;（未识别文件强制下载） - 调试友好用：
default_type text/plain;（方便查看内容） - 放在
http块最稳妥，避免location内遗漏导致继承失效
验证是否生效，排查常见问题
配置不是写完就起作用，必须校验并重载；验证最直接的方式就是看响应头。
- 执行
nginx -t && nginx -s reload才能生效 - 用
curl -I https://yoursite.com/app.js查Content-Type: application/javascript - 查
curl -I https://yoursite.com/icon.avif是否返回Content-Type: image/avif - 若返回
text/html或text/plain，说明没匹配上：优先检查types是否漏写、拼写错误（比如wof2少了个f）、或include路径不对 - 注意
location ~* \.(js|css)$这类正则块里若没继承types，需确认其所在作用域是否包含或可访问到types块
ThinkPHP 等框架的特殊处理建议
ThinkPHP 项目常涉及混合资源（静态文件 + PHP 路由入口），MIME 配置要兼顾前后端。
- 确保
default_type text/html;——否则/index.php这类无后缀的入口可能被当成纯文本下载 - 在
server块中内联完整types，比全局复用mime.types更可控，尤其适用于前后端分离部署 - 对 API 接口返回的
.json或.api，明确映射为application/json - 对日志、构建产物等非标准扩展（如
.log、.wasm），提前补全映射
