S14-J02 · 打包分析：找出最大的 JS

适用读者：首屏慢、但不知道"哪个文件大"的人。
前置：S14-B05。
实测环境：Vite 5.4.21 / Vue 3.5（2026-11-05）。
覆盖旧文：395(366) 397(396) = 762 点。
覆盖扩展：E-S14-008（体积分析方法）。
上一篇：S14-J01 · Vue Router：模式与进阶
下一篇：S14-J03 · 预压缩与 CDN。

1. 一句话结论

打包分析的第一步不是装可视化插件，而是看构建输出——Vite 已经把每个 chunk 的原始体积和 gzip 体积列出来了。

实测（默认构建）：

dist/index.html                 0.19 kB │ gzip:  0.17 kB
dist/assets/index-HVKwxhDy.js  66.71 kB │ gzip: 26.35 kB

实测（按 vendor 拆分后）：

dist/assets/index-BIw9uBUq.js   0.94 kB │ gzip:  0.55 kB
dist/assets/vendor-DyNhfkPR.js 65.85 kB │ gzip: 25.94 kB

结论：97% 的体积是 Vue 运行时（vendor），业务代码只有 0.94 kB。

2. 三种分析手段（E-S14-008）

手段	成本	能看到什么
构建输出	零	每个 chunk 的体积
`manualChunks` 拆分	低	哪些依赖占大头
可视化插件（rollup-plugin-visualizer）	中	模块级 treemap
`--sourcemap` + 分析工具	中	具体到函数

判据："先看输出够不够？" 多数量级问题（"哪个库最大"）看输出就够。

3. 实测：代码分割让首屏变小

const load = () => import('./lazy.js')     // 动态导入

实测产物：

dist/assets/lazy-woZh4iwD.js   0.11 kB │ gzip:  0.13 kB    ← 独立 chunk
dist/assets/index-EE8z-qKl.js  2.07 kB │ gzip:  1.10 kB
dist/assets/vendor-DyNhfkPR.js 65.85 kB │ gzip: 25.94 kB

观察	结论
`lazy-*.js` 单独成 chunk	动态导入 = 按需加载
vendor 不变	运行时无法省（除非换框架）

4. 体积优化的优先级

① 先拆：manualChunks + 路由懒加载（改配置，收益大）
② 再换：大库找轻量替代（如 moment → dayjs）
③ 再裁：只 import 需要的部分（按需引入组件库）
④ 最后：压缩/gzip/Brotli（J03，不改代码）

"为什么先拆再压"：拆解决"首屏要下多少"，压缩解决"传输多大"——两者不可互替。

5. 五个误区

误区	真相
"装个分析插件就能优化"	先看构建输出更直接
"vendor 大是业务问题"	是框架运行时（实测 97%）
"压缩能替代拆分"	压缩只减传输，不减解析成本
"懒加载越多越好"	首页懒加载会拖慢首屏
"体积小就一定快"	还要看请求数与解析时间

6. 自检

默认构建与拆分后，vendor 占多少？
三种分析手段的成本与能力？
动态导入产生了什么？
优化的四个优先级？
为什么"先拆再压"？

7. 下一篇

S14-J03 · 预压缩与 CDN

分析讲完，下一篇把传输成本压下去：gzip_static 与 CDN 的真实收益（含实测压缩率）。

本篇属于系列《S14 · 前端与可视化》。旧文来源：A-395/397；扩展点 E-S14-008。全部体积为 Vite 5.4.21 实测。