Node.js模块加载机制中，有路径无后缀时优先查找同名.js文件，再查同名文件夹下的index.js或package.json中main指定入口；无路径无后缀时先查内置模块，再沿node_modules逐级查找。
模块加载器本身不检查文件后缀，它只关心服务器返回的 Content-Type 响应头是否符合规范。所谓“无效文件后缀”引发的 MIME 错误，其实是路径配置或服务端响应失当导致的间接结果，不是后缀本身被拒绝。
浏览器对模块脚本的 MIME 类型有硬性要求
当你写 <script type="module" src="app.js"></script>，浏览器会发起一个 HTTP 请求去获取 app.js。此时它期望服务器返回的响应头中包含：
-
Content-Type: application/javascript（推荐） - 或
Content-Type: text/javascript
如果实际返回的是 text/plain、text/html、application/octet-stream 等非 JavaScript 类型，浏览器就会中断加载，并报错：“Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of 'xxx'”。这个检查是强制的、不可绕过的，由 HTML 规范定义。
为什么常见“后缀问题”？根源在服务端配置或路径错误
所谓“无效后缀”，比如 .mjs、.ts、.jsx 被拒，并非浏览器识别不了这些扩展名，而是：
- Web 服务器（如 Nginx、Apache）未配置对应后缀的 MIME 映射，导致默认返回
text/plain - 开发时直接双击打开 HTML 文件（
file://协议），浏览器无法为本地 JS 文件设置正确 MIME 类型，一律按text/plain处理 - 路径写错（如
src="scripts/app.mjs"实际文件不存在），服务器返回 404 页面（Content-Type: text/html），模块加载器收到 HTML 内容而非 JS，立刻报错
安全层面：MIME 检查本质是内容可信边界控制
严格 MIME 校验不是为了拦后缀，而是防止“内容冒充”。例如：
- 攻击者诱导页面加载一个看似 JS 的资源（如
log.php?callback=alert(1)），若服务器错误返回text/javascript，这段 PHP 输出就可能被当作 JS 执行 - 上传接口若未校验真实 MIME 类型，用户上传伪装成
.js的 HTML 文件，再被type="module"加载，就可能触发 XSS
因此，服务端需确保：静态资源路径准确、后缀有明确 MIME 映射；动态脚本（如 PHP/Python 生成的 JS）必须显式设置 Content-Type: application/javascript，且内容本身是合法 JS 模块语法。
实用排查与修复建议
- 打开浏览器开发者工具 → Network 标签 → 找到报错的模块请求 → 查看 Response Headers 中的
Content-Type - 确认该 URL 是否能直接在浏览器地址栏访问，是否返回预期 JS 内容（而非 404 页面或下载弹窗）
- 本地开发避免用
file://，改用http://localhost（如 VS Code Live Server、npx serve） - Nginx 配置中添加：
location ~ \.mjs$ { add_header Content-Type application/javascript; } - Node.js/Express 中提供模块文件时，手动设置头：
res.setHeader('Content-Type', 'application/javascript');
