Vite 动态 import 路由分包后首屏仍然很大怎么查

Vite 路由已经改成动态 import()，首屏却没有明显变小，最常见的原因不是“分包没有生效”，而是大依赖仍从入口静态引入，或者多个入口共享的依赖被放进了首屏公共 chunk。排查时不要只看路由文件，要同时看入口的静态依赖、共享 chunk、异步 CSS 和构建 manifest。

先确认路由真的形成了异步入口

一个可靠的路由边界应该让页面组件出现在 import() 里面，而不是先静态导入再交给路由器。Vite 文档说明，符合规则的动态导入会在生产构建中拆成独立 chunk；但这只对动态导入边界负责。

const routes = [
  {
    path: '/reports',
    // 只有进入报表路由时才请求页面模块。
    component: () => import('./pages/ReportsPage.vue'),
  },
];

如果 main.ts、根布局或全局插件仍然写着 import * as chart from 'large-chart-lib'，这个库依旧会沿入口静态依赖进入首屏。先搜索入口、布局、路由注册文件和全局插件，确认重型库没有被这些位置提前引用。

用 manifest 区分首屏依赖和懒加载 chunk

构建时打开 manifest，得到的是比文件名更可靠的依赖关系。Vite 生成的 manifest chunk 可以记录静态 imports、动态 dynamicImports、CSS 和资源文件。可以先执行：

# 生成生产产物和依赖清单，先观察再改分包策略。
npx vite build --manifest

打开 dist/.vite/manifest.json 后，从 HTML 入口对应的 chunk 开始看：imports 是首屏入口需要追踪的静态依赖，dynamicImports 则指向路由等异步入口。若最大的库出现在入口链路的 imports 中，路由动态 import 并没有解决它；若它只出现在某个动态入口，首屏变大就要继续检查预加载、共享 chunk 和 CSS。

沿共享依赖回溯首屏为什么仍然很大

首屏大通常有三种具体来源。第一，公共入口直接引用图表、编辑器、地图等只在少数页面使用的库。第二，多个路由都依赖同一个大模块，打包器为了复用把它抽成共享 chunk，而首个路由也因此加载它。第三，页面代码已经拆开，但全局 CSS、字体或资源仍在入口链路。

改动顺序建议是：先把只属于报表页的库移入报表页模块；再重新构建并观察共享 chunk；最后才考虑使用当前 Vite 对底层 Rolldown 的构建配置做更细的分组。不要看到一个巨大 vendor 文件就直接按包名硬拆，因为共享依赖的真实代价取决于用户首个任务和后续导航。

// reports-page.ts
// 大型依赖只在报表页面使用，避免入口文件提前静态加载。
export async function renderReport(canvas) {
  const { Chart } = await import('large-chart-lib');
  return new Chart(canvas, { type: 'line' });
}

重新构建时检查这四个结果

每次调整后固定看四件事：入口 chunk 是否减少了只在后续页面使用的依赖；首个路由是否仍需下载共享 chunk；异步 CSS 是否跟随目标页面而不是全局进入；页面第一次交互是否因为请求数量增加而变慢。Vite 也提供 vite:preloadError 事件处理动态 chunk 加载失败，但它解决的是发布后旧 chunk 或缓存问题，不会让首屏体积变小。

因此，首屏优化的验收标准不是“chunk 数量越多越好”，而是首个用户任务的依赖链更短、共享边界有理由、后续路由仍能按需加载。把构建前后的 manifest 保存下来，比较入口 imports 和动态入口 dynamicImports，比只盯着文件名或某个压缩后数字更容易复盘。

相关问题

动态 import 写了为什么还是首屏加载？

先检查同一个依赖是否又被入口、根布局或全局插件静态 import；动态边界不会抵消另一条静态依赖链。

是不是把 vendor 拆得越细越好？

不是。拆分要结合首个任务和后续导航判断，过度拆分可能增加请求、预加载和缓存管理成本。

只看 dist 文件大小够不够？

不够。应同时看 manifest 的 imports、dynamicImports、CSS 和资源关系，确认大文件属于首屏、共享路径还是异步路径。