JavaWeb必学：前端工程化基础(Node.js/npm/Webpack)

学JavaWeb学到这里，突然冒出来一门“前端工程化”，很多人的第一反应是：我一个写Java后端的，为什么要学Node.js、npm、Webpack这些东西？这一章其实卡在很多同学学习路线的中间节点上，前面的MySQL、SSM、IDEA部署都折腾完了，后面又要面对前后端分离、Vue这类框架，如果不把前端工程化的底子打好，到了做完整项目的时候会很被动。这一篇就把第七章“前端工程化（上）”的核心内容重新梳理一遍，围绕Node.js环境、npm包管理、Webpack的基础用法展开，全程用JavaWeb开发者的视角去理解，尽量把每个概念都拆开揉碎讲清楚。

这一章能解决什么问题，一句话总结：让原本只能扔在webapp目录下、靠浏览器顺序引用的静态资源，变成一个可以模块化开发、自动打包、自动刷新、方便联调的前端工程。适合正在学JavaWeb、刚接触Vue之前需要补前端工具链的同学，也适合那些一直用传统方式写JSP+JS、想了解现代前端工作流的后端开发者。

1. 为什么JavaWeb阶段要插进来一门“前端工程化”

1.1 传统JavaWeb项目里的前端资源有多痛

先回忆一下还没有前端工程化之前，一个典型的JavaWeb项目长什么样。webapp目录下面堆着一堆css、js、images，页面上想要引入某个jQuery插件，得手动去网上找一个js文件下载下来，放到js目录里，然后在JSP或者HTML里写<script src="js/jquery.min.js">。如果项目里还要引bootstrap、echarts、layer弹层组件，那script标签一个接一个，顺序还不能乱，比如要用jQuery插件，必须先引jQuery再引插件，否则浏览器直接报错。

更头疼的是命名和更新问题。今天改了一个公共样式文件，明天又加了一个新页面，时间一长，js目录里会出现一堆类似index_20240601.js、index_final.js、index_final_v2.js这种名字。等部署上线的时候，根本分不清哪个是最终版本。而且所有静态文件都是明文放在服务器上的，体积大、请求多、没有压缩和混淆，稍微大一点的项目，光加载静态资源就要好几秒。

这些问题本质上不是“多写几行代码”能解决的，而是整个前端资源的管理方式出了问题。模块拆不开、依赖理不清、版本管不住、性能优化无从下手。前端工程化要做的，就是把这些散乱的静态文件变成一种规范的、可管理的工程形态。

1.2 前端工程化到底“工程化”了个啥

这个词听着玄乎，拆开看就是几件事：模块化、构建、自动化、规范化。

模块化是把一个页面拆成很多小文件，每个文件只负责一个功能，比如header.js管顶部导航，goodsList.js管商品列表，页面里只要引入入口文件，内部依赖由工具自动梳理。构建是把这些模块文件经过编译、转译、压缩、合并，最终生成浏览器能高效运行的静态资源。自动化是改完代码保存一下，页面自动刷新，不用每次手动重新打包。规范化则是通过ESLint、Prettier这类工具统一代码风格，避免不同人写的代码风格差异过大。

这一连串动作里，最核心也是最基础的工具就是包管理器npm和打包器Webpack。npm负责解决“依赖从哪来、版本怎么锁”的问题，Webpack负责解决“模块怎么组织、打包成什么样”的问题。这两个工具联起来，就是前端工程化的地基。第七章“上”篇的核心内容，就是把这块地基打牢，后面再学Vue或者React的时候，脚手架就是建立在这套工具之上的。

1.3 这一章“上”篇究竟要掌握到什么程度

课程把前端工程化拆成上下两部分，上篇重点在“工具链基础”，不会一上来就让你写复杂的组件，而是分三条线往下推：第一条线是Node.js和npm环境，搞清楚它是干嘛的、怎么装、怎么管理依赖；第二条线是Webpack的核心概念，弄清楚入口、出口、加载器、插件、模式这五个关键词；第三条线是开发服务器，也就是平常说的devServer，把“写完代码自动刷新页面”这套开发体验跑起来。

下篇才进入更完整的前端工程实践，比如多页面应用、Source Map、代码分割、环境变量拆分这些内容。所以这一篇看的时候不要贪多，重点是把“项目是怎么从源代码变成浏览器能跑的静态资源”这条主线打通。这条主线一旦通了，后面看任何脚手架配置文件都不会再心虚。

2. 环境准备：Node.js与npm的安装配置

2.1 为什么需要Node.js，Java选手别慌

很多JavaWeb初学者听到Node.js第一反应是“我又要学一门新后端语言了”，其实不是。Node.js本质上是一个JavaScript运行时环境，你可以把它理解为JavaScript版的JVM。JavaScript原本只能在浏览器里跑，Node.js让它能在操作系统上直接运行，于是就用它来写一些命令行工具、构建脚本、本地开发服务。Webpack、npm、Vue CLI这些前端工具全是基于Node.js运行的，所以它是整套前端工程化的地基。

JavaWeb学习者理解这个特别容易：你写好的Java代码，靠JVM来解释执行；前端工具里的JavaScript代码，靠Node.js来运行。装好Node.js之后，不是让你去写服务器，而是让你能在本地命令行执行各种前端工具命令，比如npm install、npx webpack这些。想通这一点，就不会对这个环境有抵触了。

安装的时候有个版本选择的讲究。去Node.js官网下载，注意选LTS版本，也就是长期支持版。LTS版本的特点是稳定、兼容性好、社区插件基本都适配，不会出现今天装完明天某个包不兼容的情况。不要在官网首页看到最新版就点下载，最新版通常属于Current版本，虽然新特性多，但一些老项目跑起来容易有坑。我用的是Node 18 LTS，实测下来配合Webpack 5和Vue 3都非常稳。

2.2 安装步骤与配置细节

Windows安装没什么好说的，下载.msi安装包一路Next就行。安装完验证一下环境有没有生效。打开命令行，分别输入：

node -v npm -v

能正常输出版本号，比如v18.20.4和10.7.0，环境就OK了。这里有个容易忽略的问题：如果你之前电脑上装过老版本的Node.js，升级新版之后最好把C:\Users\你的用户名\AppData\Roaming\npm目录下的旧全局包重新装一遍，否则后面执行全局命令时可能用到旧版本残留文件。

npm默认下载源是国外的官方源，国内用户执行npm install经常卡在等待响应，有时候装一个包要好几分钟甚至直接超时。这一步非常建议提前配置成国内镜像。现在比较常用的是淘宝镜像源，命令行执行：

npm config set registry https://registry.npmmirror.com

配置好之后可以用npm config get registry验证一下，输出的地址是npmmirror就说明切换成功。这个配置是写到用户级别的.npmrc文件里的，也就是说只对当前电脑当前用户生效，不会污染项目，非常干净。

2.3 用npm初始化项目和package.json解读

环境装好之后，拿一个空目录来体验一下npm的工作方式。进入目录，执行：

npm init -y

这个命令会自动生成一个package.json文件。JavaWeb学习者看到这个文件，最直观的理解就是：它的作用类似于Maven项目里的pom.xml。pom.xml里记录项目依赖了哪些jar包、版本是多少，package.json里记录的则是项目依赖了哪些npm包、版本是多少。两者都是“依赖清单+项目元信息”的载体。

打开生成的package.json，会看到这些字段：

{ "name": "demo", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC" }

name和version是项目名和版本号，上线写包名时必须要用。scripts这一项特别重要，它是命令的别名配置区，后面要执行的构建、启动命令都定义在这里，相当于把一长串命令封装成一个短单词。比如配置了"dev": "webpack serve"之后，在命令行输入npm run dev就能启动开发服务器，不用每次敲一长串参数。

2.4 踩坑记录：镜像、缓存与IDEA终端

第一次用npm最常踩的坑有两个。一个是全局包装到一半报错，提示权限不足，这种情况在Mac和Linux上常见，Windows下偶尔也有。解决办法不是去改目录权限，而是尽量避免用全局安装，项目内依赖都通过npm install装到本地node_modules目录，全局只装那些必须的命令行工具，比如npm install -g @vue/cli。

另一个坑是安装过程中如果Ctrl+C中断了，node_modules目录可能处于半残缺状态。下次再执行npm install时，最好先把node_modules删掉，连同package-lock.json一起删掉再重新装，不然容易出现模块找不到的诡异问题。package-lock.json这个文件简单说就是“依赖锁文件”，它把实际安装的精确版本号全部锁定了，保证不同电脑上执行npm install装出来的依赖完全一致。平时用IDEA开发的时候，命令行窗口直接使用IDEA自带的Terminal面板，就不用额外开一个黑窗口了。

IDEA里面还有个小配置值得做。打开File | Settings | Languages & Frameworks | Node.js，设置Node解释器路径为安装目录下的node.exe。设置好之后，IDEA就能识别node_modules里的包，写代码时对require进来的模块也能跳转、补全，开发体验提升非常明显。另外IDEA右侧工具栏会自动识别项目里的package.json并显示一个npm工具窗口，双击里面的dev或者build脚本就能直接执行，效果和命令行手动敲npm run一模一样，我后来基本都靠这个窗口跑命令。

3. Webpack核心概念和第一个打包示例

3.1 Webpack是什么：打包器的工作逻辑

npm只是把依赖装进来了，真正处理代码的是Webpack。Webpack官方的定位是“静态模块打包器”。怎么理解这个定位呢？拿JavaWeb里的场景打个比方，你写项目的时候不会把几百个Java类全堆在同一个文件里，而是拆到不同的包、不同的类里，通过import互相引用，最后交给Maven统一编译打包成一个war包。Webpack做的事情就类似：你的代码会拆分成很多JS模块，可能还包含CSS、图片、字体这些资源，Webpack从一个入口文件开始，顺着代码里的import语句一路找依赖，摸清整棵依赖树，把所有模块打包成少数几个静态文件，输出到指定目录。

以前页面上要引四五个script标签，打包之后变成一个bundle.js文件，标签只需要一个。更重要的是，Webpack在“摸清依赖”的过程中，可以进行各种加工：把ES6语法转成ES5、把Less编译成CSS、把图片转成base64、把代码压缩混淆。这些加工的能力不是Webpack天生自带的，而是靠加载器（Loader）和插件（Plugin）来实现，这也是Webpack最核心的设计理念。

3.2 五大核心概念：Entry、Output、Loader、Plugin、Mode

Webpack的配置虽然看起来选项很多，但骨架就是五个概念。

Entry是入口。它指定Webpack从哪个文件开始分析依赖，相当于Maven里的编译根路径。最常见的是一个HTML页面配一个入口，单页应用里通常只有一个入口。

Output是出口。它告诉Webpack打包完成后把文件放到哪个目录、叫什么名字。可以只配置一个path和一个filename，但实际项目中经常配合占位符使用，后面会讲到多入口的情况。

Loader是加载器。Webpack本身只能识别JavaScript模块，遇到CSS、图片、字体这类文件就会直接报错。Loader的作用就是把这些文件“翻译”成Webpack能处理的模块。用JavaWeb来类比的话，你可以把Loader理解为各种转换器，就像MyBatis把Mapper文件转成可执行的SQL映射一样，不同后缀的文件有不同的Loader来处理。

Plugin是插件。插件的能力比Loader更广，Loader只管单个文件的转换，插件可以干预整个打包流程，比如生成HTML文件、拷贝静态资源、压缩代码、分析打包体积。后面的章节会用HtmlWebpackPlugin来验证这项能力。

Mode是模式。Webpack对开发和生产两套场景提供了预设，development模式下打包速度更快，代码不压缩，方便调试；production模式下会做全面压缩和优化，产物体积更小，适合上线。

3.3 第一个webpack.config.js配置

动手搭建之前，先要在项目里安装Webpack本体和命令行工具：

npm init -y npm install webpack webpack-cli -D

注意这里的-D，它表示这两个包属于devDependencies，也就是“开发依赖”。为什么要区分开发依赖和生产依赖呢？因为Webpack只在开发构建时起作用，真正上线运行的是打包后的静态文件，服务器并不需要Webpack。同理，像Vue、Element Plus这种运行时要用的库，就应该用npm install vue element-plus直接装，不带-D，它们会进入dependencies。

接下来在项目根目录创建webpack.config.js：

const path = require('path'); module.exports = { entry: './src/index.js', output: { path: path.resolve(__dirname, 'dist'), filename: 'bundle.js' }, mode: 'development' };

这段配置的含义是：从src/index.js开始打包，打包结果输出到dist/bundle.js，使用开发模式。

path.resolve(__dirname, 'dist')这一句是从当前配置文件所在目录出发，拼接出dist目录的绝对路径。为什么不能直接写'./dist'？因为Output的path选项要求填写绝对路径，相对路径会直接报错。第一次写Webpack配置的同学十个里有八个卡在这个点上。

入口文件里先写一行最简单的测试代码：

console.log('hello webpack');

然后执行打包命令：

npx webpack

看到命令行输出一个dist/bundle.js，同时控制台显示webpack compiled successfully，第一个打包就跑通了。留意一下npx这个词，它的作用是执行项目本地node_modules里面的Webpack命令。如果直接敲webpack，系统会去全局环境里找，大概率提示“webpack不是内部或外部命令”，这个问题摆在第六节一起说。

3.4 入口与出口的细节：多页面项目怎么配

单入口的配置很简单，入口出口各一行就完了。但JavaWeb项目的特点是多页面，一个后台管理系统可能有登录页、首页、用户管理页、订单管理页，每个页面都要有自己的入口JS，不可能全部揉在一个入口里。这时候entry可以写成对象形式，output的filename里用[name]占位符匹配入口的名字：

module.exports = { entry: { index: './src/js/index.js', login: './src/js/login.js', user: './src/js/user.js' }, output: { path: path.resolve(__dirname, 'dist'), filename: '[name].bundle.js' }, mode: 'development' };

这样打出来的不是单个bundle.js，而是index.bundle.js、login.bundle.js、user.bundle.js三个文件。每个页面对应自己的一份打包产物，互不干扰。理解了这个配置，后面看到Vue CLI生成的多页面项目结构就不会觉得奇怪了。

顺便说一个JavaWeb场景里的组合方法：打包产出的dist目录，在传统项目中可以直接把内容拷贝到webapp目录下，让后端服务器统一托管静态资源，也可以部署时通过Maven插件把前后端一起打包。现在更主流的前后端分离开发方式是各自独立部署，前端静态资源放Nginx，后端接口单独跑，这一章先不展开部署层面的问题，但心里要清楚：打包出来的dist就是可以被任何静态服务器托管的一堆文件。

4. 资源加载器实战：CSS、图片、字体和ES6转译

4.1 为什么Webpack一遇到CSS就报错

先把目录结构升级一下，改成实际项目的样子。在src下加一个css目录，里面放一个style.css：

body { background-color: #f5f5f5; margin: 0; padding: 20px; }

然后在src/index.js里引入它：

import './css/style.css';

再次执行npx webpack，大概率会收到一段红色报错，内容类似Module parse failed: Unexpected token，报错位置指向CSS文件里的大括号。这个报错其实很正常，它揭示的是Webpack的内置能力边界：Webpack默认只能把JS模块当成模块来解析，CSS后缀的文件它不认识，更不知道怎么转换。要让它认识CSS，就得借助Loader。

这背后的机制也不复杂。Webpack在遍历依赖图的时候，只要发现自己解析不了的模块，就会按配置的module.rules规则挨个匹配，找到符合后缀名的Loader，把文件内容交给它处理，Loader处理完再还给Webpack，继续后续流程。如果所有规则都没匹配上，就只能抛错。

4.2 style-loader和css-loader的组合逻辑

处理CSS文件的标准组合是装这两个Loader：

npm install css-loader style-loader -D

然后修改webpack.config.js:

module.exports = { entry: './src/index.js', output: { path: path.resolve(__dirname, 'dist'), filename: 'bundle.js' }, module: { rules: [ { test: /\.css$/, use: ['style-loader', 'css-loader'] } ] }, mode: 'development' };

test字段是正则表达式，用于匹配文件后缀，/\.css$/表示匹配以.css结尾的文件。use数组里写的是处理这些文件的Loader列表。

这里有一个无数新手踩过的坑：Loader的执行顺序是从右往左的，也就是数组最后一个先执行。所以css-loader先执行，它负责解析CSS文件里的@import、url()这些语法，把CSS变成Webpack能管理的模块；然后style-loader再执行，它的作用是动态创建一个<style>标签，把上一步解析出来的样式以字符串形式插入到页面里。顺序如果把两个Loader写反了，打包不会报错，但页面样式完全加载不出来。

这一套机制用JavaWeb来类比，就像你提交一个请求要经过两个过滤器，第一个过滤器解析参数，第二个过滤器渲染视图，顺序反了，参数没解析完视图已经没人处理了。

4.3 图片与字体资源：Webpack 5的资源模块

项目里除了CSS，还会用到图片、字体文件。Webpack 4时代处理这些资源需要额外装file-loader和url-loader，到了Webpack 5，官方直接把常见的资源加载方式内置成了资源模块，不用再装Loader，配置量一下子少了很多。

资源模块一共有四种类型，实际项目里最常用三种。asset/resource会把图片文件原样输出到dist目录，同时生成一个访问URL，相当于以前的file-loader；asset/inline会把体积较小的图片转成base64字符串直接嵌入JS代码，相当于url-loader的limit效果，好处是减少HTTP请求，坏处是文件体积变大；asset是自动模式，它会在前两者之间自动选择，小于8KB的转base64，大于8KB的输出到文件。生产环境一般用asset就能覆盖绝大多数场景。

配置写法如下：

module: { rules: [ { test: /\.(png|jpe?g|gif|webp)$/, type: 'asset', parser: { dataUrlCondition: { maxSize: 8 * 1024 } } } ] }

这段配置的意思是：遇到图片后缀的文件，让Webpack按asset类型处理；maxSize设为8KB，小于这个尺寸的图片转base64，大于的走单独文件输出。字体文件和SVG也可以用类似的规则处理，把test改成对应后缀就行。

图片处理的实际场景里有个容易忽视的问题：打包后的图片路径。如果配置里不额外指定outputPath和publicPath，Webpack会把图片输出到dist根目录，HTML页面引用时相对路径可能对不上。多数项目中会在资源模块里顺手加一句generator: { filename: 'images/[name][ext]' }，让图片统一输出到images子目录，资源多了之后目录不会乱。

4.4 babel-loader：让老板的旧浏览器也能看懂你的ES6

现在的项目代码里全是箭头函数、解构赋值、模板字符串这类ES6+语法，但有些用户的电脑上还跑着老旧浏览器，并不认识这些语法。Babel做的事情就是“语法翻译”，把源代码里的高级语法转换成ES5版本，让旧浏览器也能正常执行。

安装Babel相关的包：

npm install babel-loader @babel/core @babel/preset-env -D

三个包的职责分别是：babel-loader是Webpack和Babel之间的桥，@babel/core是Babel的核心编译引擎，@babel/preset-env是预设，它告诉Babel按什么标准去做转换，默认目标就是支持ES5环境。

配置里加一条规则：

{ test: /\.js$/, exclude: /node_modules/, use: { loader: 'babel-loader', options: { presets: ['@babel/preset-env'] } } }

exclude字段一定不能少，它的作用是让Webpack跳过node_modules目录。这个目录里全是第三方库，它们自身往往已经处理过兼容性了，不需要再让Babel过一遍。如果不排掉，打包速度会慢到怀疑人生，因为Babel要把上万个第三方文件从头到尾编译一遍。

学到这里可能会产生一个疑问：前面打包console.log的时候也没配Babel啊，不也正常跑了？这其实是因为Webpack自带了对ES6模块语法的解析能力，import和export它能直接识别。但像箭头函数、async/await这部分内容，Webpack不会动，必须交给Babel转换。这是一个新手特别容易混淆的点：Webpack负责模块打包，Babel负责语法降级。

5. 开发服务器与热更新：前后端联调的正确打开方式

5.1 手动打包的体验有多折磨

到目前为止的操作流程是：改代码，命令行执行npx webpack，刷新浏览器看效果。代码复杂了之后，每次改动都要重新打包，一旦打包速度慢，整个开发节奏就被打乱了。更要命的是，打包出来的是一个压缩过的bundle.js，出错之后很难定位到底是源码哪一行的问题。

解决这个问题的标准方案是引入开发服务器，也就是webpack-dev-server。它的作用和IDEA里部署Tomcat类似：起一个本地HTTP服务器，托管打包后的资源，同时监听源码文件的变化，一旦发现文件变更，就自动重新编译并通知浏览器刷新。开发者只需要开着浏览器，专注改代码就行。

安装并启动：

npm install webpack-dev-server -D

然后在webpack.config.js里增加devServer配置：

devServer: { port: 8081, open: true, hot: true, static: './dist' }

由于我们配置了scripts，可以直接在package.json里注册一条启动命令：

"scripts": { "dev": "webpack serve" }

然后执行：

npm run dev

控制台会输出webpack compiled successfully，随后浏览器自动打开http://localhost:8081。此时试试改一下src/css/style.css里的背景色，保存，留意页面变化：不是整个页面刷新，而是样式瞬间被替换了。这个效果就是HMR，热模块替换。它的原理是Webpack在编译时给模块打了标记，浏览器和开发服务器之间维护了一条WebSocket连接，文件变动后，服务器只推送变更的模块到浏览器，由运行时接手替换，而不是重新加载整个页面。开发体验提升非常明显，尤其是后面做表单页面的时候，不用再担心改几行样式表格数据就没了。

5.2 devServer常见配置项的取舍

devServer里有一部分配置属于必配级别，还有一部分按需配置即可。

port指定端口，默认8080，但如果本机后端项目已经占了8080，前端开发服务器最好换个端口，避免冲突。open设为true会在启动后自动打开默认浏览器，省掉手动输入地址的步骤。hot开启热更新，Webpack 5里配合webpack serve使用时，只要mode是development，大部分情形下不需要额外配置插件就能生效。实际项目中如果遇到热更新不生效，不要急着去怀疑配置，先看看是不是mode写成了production，或者开发服务器终端有没有报编译错误。

static用来指定开发服务器托管的静态文件目录。前面没有单独配devServer.static的时候，Webpack会默认把public目录作为静态资源根目录，如果项目根目录没有public文件夹，就输出警告。配置里写成static: './dist'的意思很明确：开发服务器把打包产物目录作为根目录提供访问。有些教程里会省掉这一项，但配置上更明确。

historyApiFallback也是一个常见配置。单页应用里使用前端路由时，直接访问http://localhost:8081/login会404，设置historyApiFallback: true后，服务器会把所有路径都回退到index.html，交给前端路由自己处理。做SPA项目时这个配置基本是必开项。

5.3 代理配置：开发环境的跨域问题怎么解决

前后端分离开发时，前端开发服务器跑在8081端口，Java后端接口跑在8080端口。浏览器访问前端页面时，如果页面里的Ajax请求直接发往http://localhost:8080，浏览器会基于同源策略把这个请求拦截下来，控制台报经典的跨域错误。解决方式可以改后端加CORS允许跨域，但更推荐的方式是在前端开发服务器上配置代理，让浏览器把请求发给同源的8081，然后由开发服务器在服务端转发给8080。因为服务器之间的请求不受同源策略限制。

配置代码：

devServer: { port: 8081, open: true, hot: true, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } }

这个配置的意思：所有以/api开头的请求都会被代理到http://localhost:8080，同时把URL里的/api前缀剥掉。比如前端发请求GET /api/user/list，最终转发到后端的地址是http://localhost:8080/user/list。changeOrigin的作用是让后端接口看到请求来源来自目标地址，避免某些后端框架校验Origin时出问题。

这个配置和JavaWeb联调是绝配。后端对应的Spring Boot接口不需要额外处理跨域，前端代码里请求地址都写相对路径，部署的时候只需要在Nginx里再配一遍类似的转发规则，代码不用改。很多人喜欢把这段配置和一整套工程环境一起放进课程笔记里，实际操作多了会发现，百分之八十的前后端联调问题都出在代理配置上，后端的接口反而很少出事。

5.4 和IDEA里传统JavaWeb运行方式的对比

习惯了在IDEA里配置Tomcat启动项目的同学，第一次接触devServer可能会有些别扭。传统的JavaWeb流程是：把war包部署到Tomcat，Tomcat启动后用8080端口访问应用，前后端代码都在同一个项目里，改完Java代码要重启Tomcat，改完JSP页面刷新浏览器就行。

前端工程化的流程完全不同：后端项目还在IDEA里正常启动，跑在8080；前端项目单独用npm run dev起一个开发服务器，跑在8081。两个进程各干各的，互不打断。后端改了接口，前端正在调试的页面不会因此重启；前端改了样式和逻辑，后端也不受影响。联调时通过代理把8081的请求转发到8080，整个过程非常顺滑。

这里给还在用传统JSP项目练手的同学一个建议：不要非把Webpack打成的前端产物塞进webapp目录才能理解，可以先在项目根目录同时放一个前端工程目录和后端项目目录，前端独立打包、独立部署，让两条线解耦。等理解了这个运行模式，后面学Vue的时候可以直接无缝切换。

6. 常见报错与排坑指南实录

6.1 高频报错速查表

前端工程化这一章接触的命令和工具多，报错信息也五花八门。真遇到报错别慌，先看错误信息最上面，大多数时候问题就写在首行。我把自己和周围同学踩过的高频问题整理成一张速查表：

很多报错反复出现的原因只有一个：Webpack版本之间差异太大。网上搜到的教程很多是两三年前的，Webpack 4的配置拿到Webpack 5上可能直接不兼容。最稳的方式是参考官方文档，或者看项目里node_modules/webpack/package.json里的实际版本号，再决定搜哪套方案。

6.2 一个打包后页面没样式的典型排查过程

有一回做完配置，打包一切正常，控制台也没有任何报错，但打开页面发现整个页面光秃秃的，一点样式都没有。当时第一反应是CSS文件路径写错了，检查了几遍也没发现问题。后来打开开发者工具，看到<head>里确实有style-loader注入的<style>标签，里面样式内容也有，就是没有应用上去。

继续排查才发现，问题出在CSS文件里写了一个不支持的CSS属性，旧浏览器在解析到某个未知属性时直接跳过了整条样式规则。当时在样式表里用了一个比较新的值，目标浏览器不认，整条背景色规则就失效了。这种问题的隐蔽性在于不报错，只有打开浏览器控制台一条一条看样式才会发现。以后遇到打包成功但效果异常的情况，先开浏览器开发者工具，看Elements面板有没有对应的标签和样式，再逐条排查。命令行报错反而是最容易处理的，浏览器里无声无息的问题才花费时间。

6.3 关于这一章学习的几点体会

学这一章的时候，有个最容易走偏的倾向：纠结于Webpack的每一个配置项、每一种Loader的进阶用法。这其实是本末倒置的。对于JavaWeb学习者来说，现阶段最重要的不是能徒手写出多么复杂的Webpack配置，而是能看懂项目的配置结构，能独立完成环境搭建，能跑起开发服务器实现前后端联调。真正复杂的配置工程，以后Vue CLI或者Vite都会帮你处理掉。

实际操作时，建议跟着做一个小实验来巩固理解。建一个极简项目，包含一个JS文件、一个CSS文件、一张小图片，然后尝试自己从零写一份完整的Webpack配置，要求做到：多入口打包、CSS和图片能正常处理、devServer跑起来修改代码自动刷新。这个小实验做完，这一章的“上”篇内容就算真正拿下了。

另外，node_modules目录不要手动去改，也不需要提交到Git仓库。项目根目录的.gitignore文件里加上node_modules/和dist/两行，这是团队协作的常识，也是很多JavaWeb学习者第一次接触前端工程时容易忽略的细节。如果看到别人的开源项目里没有忽略node_modules，那大概率是自己在这台机器上犯了什么操作失误，别照着学。