想让 webpack 缓存真正生效，chunk 命名和依赖稳定性要一起管

2019年11月24日 · 阅读需 3 分钟

全栈开发者 / 技术写作者

很多项目第一次做 webpack 缓存优化，都会先把文件名改成带 hash，觉得这样浏览器就能长期缓存了。这个方向没错，但如果 chunk 划分本身不稳定、运行时代码老是跟着变化、公共依赖和业务代码混在一起，最后会发现缓存命中率并没有想象中高。

hash 只是结果，稳定边界才是前提

浏览器是否能复用旧资源，取决于文件内容有没有变化。问题在于，webpack 的 chunk 内容并不只受你改过的那一行代码影响。模块顺序、公共依赖归属、运行时引用关系发生变化，都可能让一个本来不该变的文件重新产出新 hash。

所以只盯着文件名策略还不够，更要看 chunk 划分是否稳定。哪些是基础依赖，哪些是页面私有逻辑，哪些应该单独拆成复用层，这些边界如果一直晃，缓存自然也就跟着失效。

一个很常见的问题是，业务页面里随手引入一些重量级依赖，结果公共 chunk 被不断吸进去新内容；或者本来应该公共化的工具代码，散落在多个页面各自打包。前一种会让公共包频繁变化，后一种会让重复下载增加，两边都不利于长期缓存。

我更愿意先把“稳定且常用”的依赖和“变化快的业务逻辑”区分开。这样即便业务页面天天迭代，真正适合长期缓存的那部分资源也不至于每次都被重新打散。

很多人第一次看到“我只改了业务代码，为什么入口包和公共包都换 hash 了”，往往就是因为运行时代码和业务入口绑得太紧。模块引用关系一变化，入口文件里那部分运行时信息也会跟着变化，连带把缓存打乱。

把运行时代码和主要业务 chunk 分开考虑，通常能让变动范围更可控。这样用户二次访问时，真正需要重新拉取的只有少数变更文件，而不是整条入口链路一起失效。

我现在看 webpack 缓存策略，不会只问“有没有开 hash”。更关心的是：改一页业务代码，会连带多少 chunk 重新生成；升一个小依赖，会不会把主入口和公共层都打乱；二次访问时，浏览器到底还能复用多少资源。

长期缓存不是某一个配置开关，而是构建边界是否稳定的结果。chunk 命名、依赖拆分、运行时代码管理一起做好，webpack 的缓存才会真正开始帮你省时间。