JavaScript模块路径大小写敏感性由操作系统和运行环境决定：macOS/Windows默认不敏感但不可靠，Linux及区分大小写卷严格匹配；Webpack/Vite继承系统行为，ESLint和CI应强制校验。
JavaScript 本身不处理模块路径的大小写敏感性，真正起作用的是底层操作系统和文件系统，以及打包/运行时环境（如 Node.js、Webpack、Vite 等）如何解析文件。
Node.js 在不同系统上的行为
Node.js 的 require() 和 ESM import 路径解析依赖于文件系统。这意味着：
-
macOS（默认 APFS/HFS+）和 Windows（NTFS，默认不区分大小写）：路径
./utils.js可能成功加载./Utils.js或./UTILS.JS，即使拼写不一致 —— 这属于“偶然通过”，不是规范行为，容易引发线上问题。 -
Linux（ext4、XFS 等）和 macOS 启用区分大小写的 APFS 卷：路径必须完全匹配，
import './Components/Button.js'无法加载button.js，会直接报MODULE_NOT_FOUND错误。
构建工具（Webpack/Vite）的差异
这些工具通常在开发阶段基于文件系统读取模块，因此继承宿主系统的敏感性；但部分配置可能引入额外逻辑：
- Webpack 默认使用 Node.js 的解析逻辑，
resolve.extensions和别名（resolve.alias）不会绕过大小写校验。 - Vite 基于 esbuild 或 Rollup 解析，在 Linux/macOS 区分大小写卷上严格匹配；若开发时在 Windows 写了
import '@/Services/api.js'，但实际文件是api.js（小写），部署到 Linux 服务器就会失败。 - 某些插件（如
vite-plugin-mock或自定义 resolver）若手动读取文件，可能忽略大小写 —— 但这属于非标准行为，不可依赖。
ESLint 和开发协作建议
靠系统差异“侥幸通过”极易导致团队协作和 CI/CD 失败。推荐主动约束：
- 启用 ESLint 规则
import/no-unresolved+import/no-case-sensitive-imports（需eslint-plugin-importv2.27+），可静态检测大小写不一致的导入。 - CI 流程中在 Linux 容器里执行构建和测试（例如 GitHub Actions 使用
ubuntu-latest），提前暴露路径问题。 - 团队约定统一使用小写 + 中划线的文件名（如
date-utils.js），避免PascalCase模块名与大小写混淆。
动态导入与运行时路径
import() 动态导入的字符串路径同样受文件系统限制。更危险的是，若路径来自变量或用户输入（如 import(`./pages/${page}.js`)），在大小写敏感系统中一旦 page 值与真实文件名大小写不符，就会抛出 Promise rejection。
- 不要假设
fs.readdirSync()返回的文件名大小写与 import 路径一致；应标准化（如全转小写）后再比对，或使用fs.stat()精确匹配。 - 服务端渲染（SSR）场景下，Node.js 运行环境（常为 Linux）的敏感性会直接暴露问题，比客户端更早报错。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
