webpack面试题

面试官问webpack，试题十有八九第一句是试题“说说它的打包原理”。你要是试题只答“从入口开始，递归解析依赖，试题生成bundle”，试题那基本就凉了。试题这话没错，试题但太干了，试题像背课文。试题真正能让人眼前一亮的试题，是试题你说出那个关键细节：webpack把所有模块都包进了一个函数里，叫`__webpack_require__`。试题它本质是试题个模块加载器，每个模块的试题代码都被塞进函数作用域，通过参数传入`module`、试题`exports`、`require`。这设计直接解决了全局变量污染和模块作用域隔离的问题——别小看这点，当年CommonJS在浏览器里跑不起来，就是因为没有这个包装层。

然后面试官大概率会追问loader和plugin的区别。这题我见过太多人栽跟头，答案背得溜，但一深问就露馅。记住一句话：loader是转换器，plugin是扩展器。loader只处理文件的转换，比如把TS变成JS，把SCSS变成CSS，它是个纯函数，输入文件内容，输出新内容。plugin则能触及webpack生命周期里的每一个钩子，从`emit`到`done`，它能改打包结果、能生成额外文件、能注入环境变量。我有个朋友面试时打了个比方，面试官当场点头——他说loader就像厨房里的菜刀，只负责把食材切好；plugin是整个厨房管理系统，能控制火候、决定何时上菜、甚至能加个传菜电梯。

再往下，就该问代码分割了。这题有个常见误区，很多人上来就背“用`SplitChunksPlugin`”。但面试官其实想听的是为什么需要代码分割——浏览器缓存策略。你的业务代码天天变，但第三方库像react、lodash一年都不动一次。如果不分割，用户每次更新版本都得重新下载所有JS，浪费带宽还拖慢首屏。分割后，vendor包能命中强缓存，业务代码更新时只下载几KB的增量。说到这，你可以补一句自己的实操经验：我在项目里把`react`和`react-dom`单独拆了个`vendor-react`包，体积从1.2MB降到200KB，首屏时间快了近一秒。这种具体数字，比背十遍配置都管用。

接着聊热更新（HMR）。面试官要是问你原理，别只说“websocket通信”。核心在于webpack-dev-server维护了一份模块映射表，当文件变更时，它只把变更的模块重新编译，然后通过websocket推给浏览器。浏览器端的HMR runtime拿到新模块后，会检查模块的`accept`回调——如果模块自身声明了“我接受热替换”，那就直接执行替换逻辑；如果没声明，就向上冒泡，直到找到能接受的父模块。要是顶层都没人接，那就只能整页刷新了。这里我踩过坑：有一次我改了组件里的CSS，因为style-loader处理后的模块默认接受HMR，所以样式秒更新；但改了JS逻辑后没写`module.hot.accept`，结果页面白屏，排查了半天才发现是HMR没接住，直接降级成了全量刷新。

最后说个偏门但容易翻车的点：tree shaking到底是怎么工作的。很多人以为它是webpack自己分析的，其实不是。webpack只负责标记和删除，真正的“摇树”依赖ES Module的静态结构——`import`和`export`必须在顶层，不能嵌套在条件语句里。所以你在代码里写`if (process.env.NODE_ENV === 'production')`这种判断，webpack才能静态分析并剔除死代码。但如果你用了CommonJS的`require`，那不好意思，tree shaking直接失效。我见过一个同事，把整个工具库用`module.exports`导出，结果打包体积多了30%，就是因为这个。面试时你可以反问一句：“如果用了babel，记得设置`modules: false`，不然babel会把ES Module转成CommonJS，tree shaking就废了。”这一句话，基本能镇住场面。

关于webpack，面试题翻来覆去就这几个核心，但每次都能刷掉一半人。原因无他，多数人只背结论，不理解背后的设计取舍。你要是能把每个机制的前因后果串起来，再带点自己踩坑的细节，那这场面试基本就稳了。