JavaScript模块化是项目超300行、多人协作或需复用时的必然选择；不模块化会导致var冲突、加载顺序错乱、全局污染覆盖、调试困难等问题，应使用type="module"和import()/export，避免无声明赋值与动态require。
JavaScript 模块化不是“要不要用”的问题，而是项目一旦超过 300 行、涉及多人协作或需要复用逻辑，就必然要面对的组织问题——不模块化，var 冲突、加载顺序错乱、调试时找不到函数定义，都是分分钟的事。
全局变量污染导致 ReferenceError 或静默覆盖
没有模块化时，所有脚本共享一个全局作用域。比如两个文件都声明 const utils = {...}，后加载的会直接覆盖前一个；更隐蔽的是，某处不小心写成 utils = {...}（漏了 const），就变成了全局赋值，其他模块读到的就是被篡改后的值。
实操建议：
- 立即停用无声明赋值（如
config = {api: '/v1'}），一律用const/let显式声明 - 把工具函数收进立即执行函数（IIFE）是临时解法，但无法解决依赖管理，仅适用于单页小脚本
- 现代项目直接启用
type="module"，浏览器原生支持import/export，自动隔离作用域
import 和 require 的本质区别不只是语法
import 是静态声明：必须在顶层、不能条件加载、路径必须是字符串字面量；require 是运行时调用，可出现在任意位置、支持拼接路径、能套在 if 里。但这不意味着 require 更灵活——Webpack/Vite 等工具对 import 做静态分析，才能实现 tree-shaking 和代码分割；而动态 require 会让这些优化失效。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：
- 在
if (DEBUG) { import('./debug.js') }中直接写import→ 报错：Unexpected token 'import' - 用
require('./' + name)加载模块 → 构建工具无法解析路径，打包后报Module not found
正确做法：动态导入统一用 import()（返回 Promise），例如 if (DEBUG) await import('./debug.js')。
ESM 在浏览器中运行失败的三个典型原因
即使写了 export 和 import，浏览器仍可能报 Failed to resolve module specifier 或 Cross-origin request blocked。
关键检查点：
- HTML 中 script 标签必须带
type="module"，否则浏览器当普通脚本执行，忽略import - 模块路径必须是相对路径（
./util.js）或绝对路径（/src/util.js），不能是裸包名（lodash）——浏览器不支持包名解析 - 本地双击打开 HTML 会触发 CORS，必须通过
http-server或 VS Code Live Server 启动服务
模块化本身不增加功能，但它把“谁在什么时候拿到什么代码”这件事从不可控变成可描述、可验证。最易被忽略的一点：模块路径里的 . 和 .. 是字面量，不是运行时计算结果；少一个点、多一个斜杠，错误信息可能只显示“failed to fetch”，而不是具体哪一行哪一列出了问题。
