webpack本质是模块化构建系统，核心能力体现在处理.vue/.scss、动态导入、多页html及热更新等复杂场景；entry定义依赖图起点，output通过contenthash实现精准缓存；loader按右到左链式翻译非js资源，plugin则通过生命周期钩子跨文件干预构建流程。
Webpack 不是“打包工具”这个说法能概括清楚的——它本质是个**模块化构建系统**，打包只是它最常被看到的结果。如果你只想把几个 .js 文件合并压缩，用 esbuild 或 rollup 更轻快；但一旦项目里混着 .vue、.scss、import() 动态导入、多页 HTML、热更新开发服务器……Webpack 的能力边界才真正显现。
Entry 和 Output 决定了构建的起点和终点
入口（entry）不是“要打包哪些文件”，而是“从哪个模块开始解析依赖图”。它可以是字符串、数组或对象：
module.exports = {
entry: {
main: './src/index.js',
vendor: ['react', 'lodash'] // 单独抽 vendor chunk
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash:8].js', // 避免缓存失效
clean: true // 每次构建前清空 dist
}
};
注意：output.filename 中的 [contenthash] 是关键——内容变了 hash 才变，否则浏览器可能加载旧缓存 JS。别用 [hash]（整个构建 hash），它会导致所有文件 hash 同步变化，失去长期缓存意义。
Loader 处理非 JavaScript 资源
Webpack 默认只认识 .js 和 .json。遇到 .css、.ts、.png，必须靠 loader 翻译成 JS 模块。顺序很重要：从右到左执行（类似函数式管道）。
立即学习“Java免费学习笔记（深入）”；
-
css-loader解析@import和url()，转成 JS 字符串 -
postcss-loader（带autoprefixer）补全 CSS 前缀 -
style-loader把 CSS 字符串插入<style></style>标签
常见坑：style-loader 只在开发时用（便于 HMR），生产环境应改用 mini-css-extract-plugin 提取为独立 .css 文件，否则样式会随 JS 一起下载，无法并行加载。
Plugin 改写整个构建流程
Loader 处理单个文件，Plugin 监听构建生命周期钩子，做跨文件操作。比如：
-
HtmlWebpackPlugin自动生成index.html，自动注入main.[hash].js -
DefinePlugin在编译期注入全局常量（如process.env.NODE_ENV） -
SplitChunksPlugin（默认启用）按模块引用关系、大小、复用次数自动拆分 chunk
注意：SplitChunksPlugin 的 chunks: 'all' 是默认值，但对异步 import() 加载的模块，默认不进 vendor，得显式配 cacheGroups 才能命中。很多人卡在这一步，以为配置没生效。
Mode 和 DevServer 是开发体验分水岭
mode: 'development' 不只是开 devtool: 'eval-cheap-module-source-map'，它还关掉代码压缩、开启模块路径可读、保留注释——这些都让报错堆栈可定位。而 mode: 'production' 自动启用 TerserPlugin、FlagDependencyUsagePlugin 等十多个优化插件。
devServer 的核心价值不在“起服务”，而在 hot: true + hotOnly: false 实现模块热替换（HMR）。但 HMR 不是万能的：React 组件需要 @pmmmwh/react-refresh-webpack-plugin 插件配合，否则状态丢失；CSS 修改能直接更新，但 JS 中的副作用（如定时器、全局事件监听）不会自动清理——这是开发者最容易忽略的“热更新残留”问题。
