如何理解webpack？为什么会有这项技术的广泛使用？ 从硬件来说，计算机很重要的一个问题就是寻址，包括内存、寄存、信道等 而软件层面的寻址也同等重要 webpack和XML配置、ENV配置类似，核心功能是一个集中式的地址指引 解决的是我在应用开发层面的连接问题，这和很多语言和开发环境的依赖构建是类似的 在webpack之前，代码模块化的操作需要手动或者借助第三方工具进行Comprees然后完成 类比于静态语言在拥有配置文件、IDE发展演化前也是通过类似的人工操作来完成按模块编译和导入 实际上都是类似的东西，先是有Hardware层面的"依赖管理"，即各种寻址链接；然后在BIOS上，然后是OS上，最后是Software上

如果一个项目有成百上千个入口文件怎么办？ 大批量的数据处理起来原理都是一样的，通过拆分 写Node代码，按dir来read其中的文件，手动构建文件地址，然后再进行webpack的配置

loader和plugin的区别？ plugin影响整个App, 注入于Hooks中, 用于将富文本以及其它格式的文件转为可被webpack处理的模块 Loader影响单一类型的文件, 注入于Function中, 用于扩展Webpack本身的功能 比如:

• loader(Babel loader, CSS loader)
• plugin(HtmlWebpackPlugin, TerserWebpackPlugin)

基本概念

• 入口（Entry）：指定打包的起点。
• 输出（Output）：指定打包后的文件输出位置。
• 加载器（Loader）：处理非 JavaScript 文件（如 CSS、图片）。
• 插件（Plugin）：扩展 Webpack 的功能（如代码压缩、环境变量注入）。
• 模式（Mode）：开发模式（development）和生产模式（production）。

用途

• 资源打包(hyper text file、code file)
• 语法转译 (Babel)
• DevServer开发服务器
• HMR热更新
• 性能优化(Tree Shaking & Code Split)

原理

Modularization -> Dependency Analysis -> Loader -> Plugin -> Optimization -> Output

模块图（Module Graph）

Webpack 将所有资源视为模块，通过依赖关系构建模块图 每个模块都可以通过 import 或 require 引入其他模块

依赖图（Dependency Graph）

Webpack 从入口文件（Entry）开始，递归解析模块的依赖关系，生成依赖图

Loader

Webpack 使用 Loader 处理非 JavaScript 模块（如 CSS、图片）。Loader 将资源转换为 Webpack 能够理解的 JavaScript 模块

Plugin

插件用于扩展 Webpack 的功能，例如代码压缩、环境变量注入等 通过 Webpack 的 Tapable 插件系统在打包过程中注入Hooks

Optimization

减少代码体积

• 代码分割
• Tree Shaking 移除未使用代码
• Cache

Output

将依赖图中的所有模块打包成一个或多个文件(Bundle)，并输出到指定目录