Webpack核心配置必须理解entry、output、module.rules和plugins四大模块，漏配或错配会导致打包失败；其本质是权衡决策而非简单填空，每项配置均影响运行时行为与产物结构。
模块打包工具在 JavaScript 中不是“把代码塞进一个文件”那么简单，而是解决依赖管理、资源转换、环境适配和代码分割这一整套工程问题的枢纽。Webpack 是其中最典型的代表，但它的配置不是填空题，而是一系列权衡决策的结果。
Webpack 的核心配置项有哪些必须理解
Webpack 本质是基于入口（entry）、输出（output）、加载器（module.rules）和插件（plugins）四块构建流程。漏掉或错配任一环节，打包就会失败或产出不符合预期。
-
entry不只是字符串路径：可以是数组（多入口合并）、对象（命名入口）、函数（动态生成），影响chunk切分逻辑 -
output.filename中的[name]、[contenthash]不是占位符语法糖，直接决定浏览器缓存是否生效 -
module.rules的test和use必须严格匹配资源类型，比如/\.css$/不会命中scss，需单独配sass-loader -
mode: 'development'和'production'不仅开关压缩，还默认启用不同插件（如DefinePlugin、SplitChunksPlugin），不能靠手动补全模拟
常见报错和对应排查点
Webpack 报错信息常藏在层层嵌套的日志里，真正关键的线索往往在第一行错误类型和最后的 module 路径中。
-
Module not found: Error: Can't resolve 'xxx'：检查resolve.alias是否覆盖了真实路径，或node_modules是否缺失该包（注意 peerDependencies） -
Invalid configuration object：90% 是拼写错误，比如把moduels写成modules，或optimization.splitChunks写在了顶层 -
TypeError: compiler.plugin is not a function：插件版本与 Webpack 版本不兼容，比如 v5 用 v4 插件（html-webpack-plugin@4不支持 Webpack 5） - 热更新失效（HMR not working）：确认
devServer.hot为true，且入口 JS 中调用了module.hot.accept或使用了@hot注释
如何避免配置膨胀到不可维护
Webpack 配置容易从 webpack.config.js 膨胀成十几个文件，根源在于没区分「约定」和「配置」。现代项目应优先用工具约束而非手动配置。
立即学习“Java免费学习笔记（深入）”；
- 用
webpack-merge拆分common/dev/prod，但只拆必要差异（如 source map、压缩开关），别把 loader 全拆开 - 把
babel-loader配置移入.babelrc，eslint-loader改用独立脚本（npm run lint），减少 webpack 配置耦合 - 对 CSS 处理，优先用
css-loader+style-loader组合，而非硬上mini-css-extract-plugin——后者只应在生产环境提取 CSS 文件时启用 - 升级 Webpack 5 后，删掉所有
webpack-node-externals、uglifyjs-webpack-plugin等已内置功能的插件
Webpack 的复杂性不在 API 数量，而在每个选项背后都连着运行时行为、构建产物结构和浏览器加载逻辑。改一行 output.publicPath 可能导致整个静态资源 404；加一个 noParse 可能让某个库的 ES Module 导出失效。配置不是越全越好，而是要清楚每一项“为什么存在”。
