ES Modules性能优化关键在于静态分析、轻量加载与运行时协同：用命名导出和"sideEffects"声明支持Tree Shaking，动态import()实现懒加载，合并细碎模块减少解析开销，结合Vite等工具发挥原生ESM优势。
ES Modules（ESM）在现代 JavaScript 开发中已是标准模块系统，性能优化不能只盯着语法写法，关键在于理解其静态解析、加载时机和构建链路的协同机制。核心思路是：让静态分析更充分、让实际加载更轻量、让运行时开销更可控。
利用静态结构做 Tree Shaking
ESM 的 import/export 是静态声明，打包工具（如 Vite、Rollup、Webpack 5+）能据此安全地移除未使用的导出代码。但前提是模块本身要“可摇”：
- 避免默认导出对象字面量（
export default { a: 1, b: 2 }），它会阻止对单个属性的摇树；改用命名导出：export const a = 1; export const b = 2; - 在
package.json中显式声明"sideEffects": false（或精确列出有副作用的文件），否则工具会保守保留所有模块 - 使用 ESM 版本的第三方库（如
lodash-es而非lodash），它们已按模块拆分并标记了sideEffects
控制模块粒度与加载时机
ESM 支持顶层 await 和动态 import()，这是优化首屏和按需加载的关键：
- 对非首屏功能（如弹窗组件、图表渲染器）用
const { Chart } = await import('./chart.js');实现懒加载 - 避免在模块顶层大量
import非必要依赖；把可延迟的依赖移到函数内动态导入 - 注意：动态
import()返回 Promise，适合配合 Suspense 或 loading 状态使用，不适用于同步初始化逻辑
减少解析与执行开销
虽然 ESM 是静态的，但每个模块仍需解析、编译、执行。高频小模块反而增加开销：
- 合并细碎的工具函数模块（如把
isString.js、isEmpty.js合并为utils.js），降低模块数量而非盲目拆分 - 避免在模块顶层执行复杂计算或 I/O（如读取环境变量、预请求）；这些应封装进函数，在真正需要时调用
- 确保模块文件名带
.js后缀（Node.js 中）或type="module"（浏览器中），避免解析歧义导致重复尝试
构建与运行时协同优化
ESM 的优势需构建工具和运行时共同释放：
- Vite 开箱支持原生 ESM，开发时无需打包，模块按需编译，热更新极快；生产构建默认启用
build.rollupOptions.treeshake - 在 Node.js 中启用
--experimental-loader或使用esbuild-node-loader可加速 ESM 加载，尤其适合大型 CLI 工具 - 服务端渲染（SSR）场景下，优先用 ESM 入口 +
import.meta.url定位资源，避免 CommonJS 的路径不确定性
