Vite Chunk 拆分：拆得细，不代表加载快

Vite Chunk 拆分：拆得细，不代表加载快

一、Chunk 数量不是越多越专业

Vite 构建产物拆分很容易。动态 import、manualChunks、依赖预构建都能让 bundle 看起来更清爽。但拆得细不代表加载快。请求数量增加、缓存命中变化、执行顺序复杂，都会影响真实体验。

Chunk 拆分要服务用户路径。首屏必须加载的放一起，低频功能延后，重量级第三方库按场景拆。不要为了产物分析图好看，把一个页面拆成一串小碎片。

二、拆分策略要从路由和依赖图开始

先看路由访问频率，再看共享依赖。不要先写 manualChunks。

flowchart TD A[路由访问数据] --> C[首屏关键路径] B[依赖图分析] --> C C --> D[拆分候选] D --> E[缓存策略] E --> F[构建配置] F --> G[真实加载验证]

产物分析只告诉你包里有什么，不告诉你用户什么时候需要它。两者要结合。

三、manualChunks 要少而明确

下面示例把大型但低频的编辑器拆出去。不要把所有依赖都手工分组。

export default { build: { rollupOptions: { output: { manualChunks(id: string) { if (id.includes("monaco-editor")) return "editor"; if (id.includes("echarts")) return "charts"; }, }, }, }, };

手工拆分越多，维护成本越高。依赖升级后，拆分策略也要复查。

四、拆分后要看网络瀑布

Chunk 拆完，要在真实网络下看瀑布图。是否增加阻塞请求？是否造成缓存失效？是否让首屏多等一个异步 chunk？这些比 bundle 总大小更重要。

还要看执行成本。某些库下载不大，但初始化很重。拆出去可以减少首屏执行；如果首屏必须用，拆出去反而多一次异步等待。

最后，预加载要克制。modulepreload能减少等待，但预加载太多会抢关键资源。优化不是把所有未来可能用到的东西提前下载。

长期缓存也要设计。稳定的 vendor chunk 适合长缓存，业务 chunk 更新频繁，拆分时要避免业务代码变化导致大依赖缓存失效。文件 hash 变一次，用户就要重新下载，这不是小事。

还要看错误恢复。动态 chunk 加载失败时，页面要能提示刷新或重试。移动网络下 chunk 失败并不少见。拆分越细，出现加载失败的面也越大，恢复逻辑必须跟上。

最后，拆分策略要定期复盘。依赖升级、路由调整、业务模块变化后，旧的 manualChunks 可能变成负担。构建配置不是写完就供起来的牌位。

服务端部署也要配合。静态资源要有正确的 cache-control，HTML 不能被长缓存，带 hash 的资源可以长缓存。前端拆包做得再漂亮，CDN 策略错了，用户照样加载旧代码或频繁重新下载。

Source Map 也要考虑。拆分后调试文件更多，错误堆栈映射要稳定上传。否则线上报错只看到 chunk 文件名，排查会很难受。

预加载策略也要跟路由数据联动。高频下一跳可以预取，低频页面不要提前抢资源。猜用户会去哪这件事，最好用数据说话，别靠产品感觉。

五、总结

Vite Chunk 拆分要围绕用户路径和依赖图设计。拆得细不等于加载快，manualChunks 也不是越多越专业。拆分后要用真实网络瀑布、缓存命中和执行成本验证。产物图只是线索，用户体验才是验收标准。