模块化是解决大型JavaScript项目中全局污染、依赖混乱等问题的最小必要手段；export/import强制定义依赖边界和执行时序，需顶层声明，不同导入方式影响tree-shaking与运行时行为。
JavaScript 代码需要模块化，不是因为“高大上”或“跟风”，而是当项目超过 300 行、涉及 3 个以上功能域（比如用户登录、数据请求、本地缓存）、多人协作时，var 全局污染、加载顺序错乱、重复执行、调试定位困难这些问题会立刻爆发——模块化是解决这些实际问题的最小必要手段。
什么是 export 和 import？不是语法糖，是执行约束
export 和 import 不只是“把变量拿出来”“把文件拉进来”，它们强制定义了代码的依赖边界和执行时序。浏览器或打包工具（如 Vite、Webpack）会据此构建静态依赖图，提前报错未导出的引用、循环依赖、顶层 this 指向 undefined 等问题。
-
export只能出现在模块顶层（不能在if或函数内），否则报错ParseError: 'export' may only appear at the top level -
import也必须在顶层，且所有import语句会在模块执行前解析完成（hoisted），但不会执行被导入模块的代码——直到该模块首次被调用 - 默认导出（
export default）和具名导出（export const x = 1）不能混用同一个绑定名；例如不能同时export const foo = 1和export default foo
import 的写法差异直接影响运行时行为
不同写法对应不同的绑定机制和 tree-shaking 效果，选错可能让本该被剔除的代码留在生产包里。
-
import { foo } from './utils.js'：只绑定foo，其他导出不加载；若utils.js有副作用（如初始化日志），这部分仍会执行 -
import * as utils from './utils.js'：创建命名空间对象，所有导出都可访问，但打包器无法判断你是否真的用了其中某个成员，tree-shaking 失效 -
import('./utils.js')（动态导入）：返回 Promise，支持按需加载、条件加载、错误捕获；常用于路由懒加载或降级逻辑，但不能用在if外部或循环中直接解构
常见报错：为什么 Uncaught SyntaxError: Cannot use import statement outside a module？
这个错误说明你的 JS 文件没被当作模块执行——浏览器默认以 script 模式解析，而 ES 模块必须显式声明。
立即学习“Java免费学习笔记（深入）”；
- 确保 HTML 中引入脚本时加了
type="module"： - Node.js 中需满足两个条件之一：文件扩展名为
.mjs，或package.json中设置了"type": "module" - Vite / Webpack 等工具会自动处理，但如果你手动写
fetch('./data.json').then(r => r.json())加载 JSON，注意：ES 模块不支持直接importJSON（除非配置插件），会报Cannot find module '*.json'
模块化的真正门槛不在语法，而在理解“导出即契约”——一旦 export 一个函数，它的参数、返回值、副作用就构成了外部可依赖的接口；改它，就得同步更新所有 import 它的地方。很多人卡在“能跑就行”，却在三个月后发现改一个工具函数要 grep 十个文件、测八条路径——这才是模块化最常被忽略的代价。
