webpack 通过静态分析源码构建模块依赖图谱，以入口模块为根节点，递归解析 import/require 生成 module 节点和 dependency 有向边，形成构建期的有向图，再据此生成 chunk 与最终资源。
Webpack 通过静态分析源码构建模块依赖图谱，核心在于“从入口出发，递归解析 import/require 语句，将每个模块抽象为图中的节点，依赖关系作为有向边”。
依赖图谱的起点：入口模块（Entry）
Webpack 启动时读取配置中的 entry 字段（如 ./src/index.js），将其作为图的根节点。这个文件不会被“调用”产生，而是被主动加载，是整个依赖关系的源头。
说明：
– 入口可以是一个字符串、数组或对象，支持多入口；
– 每个入口都会生成独立的依赖子图（多页面应用中常见）；
– Webpack 不执行代码，仅做语法层面扫描，因此不关心变量是否真实赋值或条件是否成立。
模块识别与递归遍历：AST 解析 + 依赖收集
Webpack 使用自研的 acorn（轻量 AST 解析器）对每个模块源码进行词法与语法分析，识别出所有 import、export、require()、require.ensure 等模块声明语句。
关键行为：
– 遇到 import './a.js'，立即推导出相对路径，生成新模块绝对路径，并加入待处理队列；
– 对于 import() 动态导入，标记为异步依赖，生成单独的 chunk 节点，不阻塞主图构建；
– require('./' + name) 这类表达式无法静态确定路径，Webpack 会警告并忽略，或按配置 fallback 到上下文（ContextModule）；
– 每个模块只被解析一次（基于绝对路径去重），避免循环引用导致无限递归。
模块抽象与图结构：Module 对象与 Dependency 实例
在内存中，每个模块对应一个 Module 实例（如 NormalModule），它持有源码、路径、构建结果等信息；而每次 import 语句则生成一个 Dependency 子类实例（如 ImportDependency），记录“谁引用了谁”以及如何连接。
图的本质体现：
– Module 是顶点（vertex）；
– Dependency 是有向边（edge），指向被依赖模块的 identifier；
– 整个图是有向无环图（DAG），但允许循环引用（此时模块 exports 在首次执行时为 {}，后续赋值才生效）；
– 图的连通性决定打包产物结构：未被任何路径可达的模块（tree-shaking 前）会被标记为“unused”，可能被剔除。
图的落地：从依赖关系到 Chunk 与资源输出
依赖图本身不直接生成文件。Webpack 会基于图做二次分组——把强连通、共用入口或满足 SplitChunks 条件的模块聚合成 Chunk，再由 Chunk 渲染为最终 bundle（如 main.js、vendor.js）。
实际影响：
– optimization.splitChunks 本质是对依赖图做子图切分；
– module.rules 中的 loader 处理发生在模块构建阶段（即图节点生成后、内容转换时）；
– 插件（如 DllPlugin）可提前固化部分子图，跳过重复解析；
– stats 输出的模块列表、大小、依赖链，就是该图的可视化快照。
不复杂但容易忽略：依赖图谱不是运行时结构，它完全在构建期静态生成，且与 JS 执行逻辑解耦。理解这点，才能真正看懂报错信息里的 “Cannot resolve module” 或 “circular dependency”，也才能合理设计代码分割和懒加载策略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
