JavaScript模块依赖解析详解

本文深入剖析了主流JavaScript模块打包器（Webpack、Rollup、Vite）如何通过静态分析而非运行时执行来精准构建依赖图，揭示了它们在处理import/require语句时的核心机制与关键差异：Webpack依托acorn解析AST并兼顾ESM/CommonJS混合场景，Rollup坚持纯ESM的严格静态分析以实现高效树摇，而Vite则利用esbuild预解析提速但将复杂逻辑交由插件接管；文章特别强调动态引入、路径拼接、Node内置模块等常见“陷阱”并非打包器的缺陷，而是静态分析范式下的必然取舍，并提醒开发者：依赖解析只认语法合法的字面量，路径错误或配置缺失不会阻断图构建，却会在后续阶段暴露问题——理解这一底层逻辑，是写出可预测、易维护、真正契合工具链的模块化代码的关键。

JavaScript模块打包器不是靠猜来解析依赖的，它通过静态分析源码中的 import、require()、define() 等语句，构建出一张明确的依赖图。动态 require()（如 require(path)）或运行时拼接模块名的情况，大多数打包器默认不处理——这不是缺陷，而是设计取舍。

Webpack 怎么扫描 import 和 require 语句

Webpack 的 Parser 在编译阶段对每个模块源码做 AST 解析（用的是 acorn），提取所有顶层 import 声明和 require() 调用。它不执行代码，所以无法识别 if (cond) require('./a') 这类条件引入，除非你显式配置 require.context()。

• import 语句全部被静态捕获，包括命名导入、默认导入、重命名、类型导入（import type）会被忽略
• require('./foo.js') 这种字面量路径能被准确解析；require('./' + name) 会被跳过，触发 ContextModule 警告
• ESM 和 CommonJS 混写时，Webpack 默认把 require() 当作 CommonJS 处理，但会尝试模拟 ESM 导出行为（需开启 experiments.outputModule 才能输出真正的 ESM）

Rollup 的依赖解析更严格，也更“纯”

Rollup 默认只处理 ESM 语法，它的依赖图是扁平且无副作用的——它会把 import { foo } from 'pkg' 编译成直接内联 foo 的定义，而不是保留一个运行时 require 调用。这也意味着它天然不支持动态 require 或 __dirname 这类 Node.js 特有变量。

• 不识别 require.resolve()、require.cache 等运行时 API，遇到就报错
• import() 动态导入会被转为异步 chunk，但路径必须是字符串字面量，不能含变量
• 如果项目里混用了 export default 和 module.exports =，Rollup 可能漏掉导出，需用 plugin-commonjs 显式桥接

Vite 用 esbuild 预解析，但仍有边界

Vite 启动时用 esbuild 快速扫描 import 语句生成依赖列表（deps），这个过程极快，但 esbuild 不解析 require()，也不处理非 JS 资源（比如 import './style.css' 是 Vite 插件层接管的，不是 esbuild 干的）。

• 开发服务器启动快，是因为 esbuild 只做最小必要解析，不走完整打包流程
• import.meta.glob('./pages/**/*.vue') 是 Vite 特有的语法糖，esbuild 完全不认识，靠插件在解析阶段重写为可识别的 import() 形式
• 如果你在 .ts 文件里写了 require('fs')，Vite 开发时可能不报错（Node.js 模块未被拦截），但构建时会失败——因为生产构建走的是 Rollup，而 Rollup 默认不处理 Node 内置模块

真正容易被忽略的是：依赖解析发生在构建前期，和代码是否能“跑通”无关。写一个语法合法但逻辑错误的 import（比如路径拼错、大小写不符、缺少扩展名），打包器照样能画出依赖图——只是后续解析模块内容时才暴露问题。路径别名、自动扩展名、条件导出这些能力，全靠配置驱动，不是自动生效的。

终于介绍完啦！小伙伴们，这篇关于《JavaScript模块依赖解析详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！