SplitChunksPlugin缓存异常：修改业务代码致Vendor哈希变更

兄弟，我太懂你这个痛点了！之前我也踩过一模一样的坑——明明只改了几行业务代码，结果vendor包的哈希跟着一起变，之前做的缓存优化完全白搭。别慌，咱们一步步把这个问题搞定。

问题根源 #

为啥改业务代码会影响vendor的哈希？核心原因有三个：

1. 哈希类型用错了：如果你的output里用的是hash或者chunkhash，前者是全局编译哈希（任何文件变全局都变），后者是基于chunk的依赖关系哈希——业务代码变更会导致chunk的依赖映射变化，vendor的chunkhash也会跟着变。
2. 模块ID不稳定：Webpack默认用递增数字作为模块ID，新增/删除业务模块会导致所有模块ID重新排序，vendor包里的模块引用ID也会变，最终导致哈希变更。
3. 运行时代码没抽离：Webpack的运行时包含模块映射关系，业务代码变更会修改这个映射，如果运行时代码和vendor打包在一起，自然会让vendor的哈希改变。

具体解决方案 #

直接上亲测有效的配置，你照着调整就行：

1. 修正Output的哈希类型

把filename和chunkFilename改成用[contenthash]，这是完全基于文件内容的哈希，只有当文件本身代码变了才会更新：

output: {
  filename: '[name].[contenthash].js',
  chunkFilename: '[name].[contenthash].js',
  // 其他配置比如path、publicPath保持不变
}

2. 优化Optimization配置

重点配置moduleIds、runtimeChunk和splitChunks，保证vendor的稳定性：

optimization: {
  // Webpack4用hashed，Webpack5推荐用deterministic（生成更短的稳定哈希）
  moduleIds: process.env.WEBPACK_VERSION === '5' ? 'deterministic' : 'hashed',
  // 把运行时代码抽成单独的包，避免业务变更影响vendor
  runtimeChunk: 'single',
  splitChunks: {
    chunks: 'all',
    cacheGroups: {
      vendor: {
        // 精准匹配node_modules里的第三方依赖
        test: /[\\/]node_modules[\\/]/,
        name: 'vendors',
        chunks: 'all',
        priority: 10, // 给vendor更高优先级，避免和其他缓存组冲突
        enforce: true // 强制拆分，不管chunk大小
      }
    }
  }
}

额外注意事项 #

• 确保你的业务代码里没有把第三方依赖的源码直接复制到项目中（比如把node_modules里的文件拷出来改），不然这些代码会被打包到业务chunk，同时可能影响vendor的依赖关系。
• 如果用了HtmlWebpackPlugin，确保它能自动引入所有生成的chunk（默认会处理，不用额外配置），这样runtime、vendor、app三个包都会被正确插入到HTML里。

这样调整之后，你再修改业务代码试试——vendor的哈希肯定不会跟着变了，缓存就能正常生效啦！

内容的提问来源于stack exchange，提问作者1252748