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-controlHTML 不能被长缓存带 hash 的资源可以长缓存。前端拆包做得再漂亮CDN 策略错了用户照样加载旧代码或频繁重新下载。Source Map 也要考虑。拆分后调试文件更多错误堆栈映射要稳定上传。否则线上报错只看到 chunk 文件名排查会很难受。预加载策略也要跟路由数据联动。高频下一跳可以预取低频页面不要提前抢资源。猜用户会去哪这件事最好用数据说话别靠产品感觉。五、总结Vite Chunk 拆分要围绕用户路径和依赖图设计。拆得细不等于加载快manualChunks 也不是越多越专业。拆分后要用真实网络瀑布、缓存命中和执行成本验证。产物图只是线索用户体验才是验收标准。