​1、背景-为什么我们要自定义打包后的文件chunk名称?

webpack默认使用的是chunkId来作为文件名称，chunkId的计算规则主要基于以下几个因素：

1. 模块依赖关系：Webpack会根据模块的依赖关系图生成chunk，相同的依赖关系可能会导致相同的chunkId。
2. 入口点：每个入口点的chunkId通常是基于其在配置文件中定义的顺序，Webpack会为第一个入口分配ID 0，依此类推。
3. 配置：你可以通过Webpack配置中的output.chunkFilename指定chunkId的格式，从而影响生成的文件名。
4. 动态导入：使用动态导入时，Webpack会为生成的chunk分配一个新的ID，通常是递增的数字。
5. 缓存优化：在某些情况下，Webpack会考虑到缓存策略，确保在生成ID时避免冲突和重复。
   最终，chunkId是一个用于区分不同chunk的唯一标识符。

chunkId是一个递增的自然数数字；而且和程序的入口点、模块间依赖关系、是否是动态导入等都有关系；虽然知道生成规则，但是并不能直观的感受到每个id的具体含义，因为这本来就是为了在生产环境“加密”的一种方式，不轻易透漏原始文件信息。

根据上面chunkId的生成规则可知，每次修改程序后生成的id不一定都是一成不变的，而是根据各种规则生成的，比如A文件原本是1.js后来是2.js这都有可能；
但是有些场景下，我们期望生成的文件名按照我们自己的想法或需求来，比如home.vue这个页面，我们希望打包后生成的文件是home.js而不是1.js，那么就需要自定义webpackChunkName了。

2、生成自定义chunkName 名称

路由和动态导入：在处理路由时，特别是使用动态导入的场景，Webpack会识别哪些模块是按需加载的，并将它们打包到不同的chunks中。
首先需要在路由上使用懒加载方式（动态导入）：
示例：

const TipPage = import(/* webpackChunkName: "tipPage" */ '@/views/TipPage')  
const router = createRouter({  
  history: createWebHashHistory(),  
  routes: [  
    {
      path: '/',  
      name: 'Home',  
      component: Home,  
    }, {  
      path: '/Tip',  
      component: TipPage,  
      name: 'Tip'  
    },
  ],
})
export default router

可以看到，我们是动态导入TipPage这个组件的，这个时候TipPage会被webpack打包成单独的chunk, 生成对应的{id}.js文件到dist目录；
但是在import给了注释，自定义了webpackChunkName，所以生成的chunk为 tipPage.js

/* webpackChunkName: "tipPage" */

实际对比参考如下：

可以看到，为自定义时生成的chunk名为 984.js 这是根据前面说的规则自动生成的一个数字，但是当遇到我们的webpackChunkName后，就按照自定义的tipPage来命名和链接该模块了。

具体的webpack config片段如下：

output: { 
  filename: assetsPath('js/[name].js'),  
  chunkFilename: assetsPath('js/[name].js'),  
  clean: true,
},
target: ['web', 'es5'],  
optimization: {
  splitChunks: {  
    chunks: 'all',  
    minSize: 200000,  
    minChunks: 1,  
    name: (module, chunks, cacheGroupKey) => {  
      const allChunksNames = chunks.map((chunk) => chunk.name).join('~')  
      return `${allChunksNames}`
    },  
  },  
},

3、更多使用场景

自定义chunkName名称还有以下用处：
1、避免服务器文件越来越多：就是说当我们的部署方式是直接提交到服务器对应目录下，而不是先删除（有时候因为存在客户自己的文件，不能删除）后部署时，每次生成不同的{id}.js文件，将导致文件越来越多，试想一下本次生成的文件叫1.js，下次改了后生成的又是999.js，那么服务器目录将残留很多历史无用的文件。
2、自定义命名那些本地加载的第三方sdk包：比如企业微信的js-sdk，我们全局导入时，采用动态导入的方式，同时指定webpackChunkName: “wx-js-sdk”，那么当这个版本的js-sdk有问题时，我们给客户直接替换新版本的wx-js-sdk.js文件即可，而不需要去找到底生成的是哪个id命名的文件。

当然，如果不需要在这些场景下或没有自定义文件名的特殊需求的话，最好是采用默认的id形式，这样符合webpack本身的默认行为和规则，在效率和性能上可能更优，尤其是大型项目，分割代码块多的场景。

​