标准答案
- 先用可视化工具或构建报告看每个 chunk 的大小、组成和依赖来源。
- 重点检查大依赖、重复依赖、多版本依赖、全量引入和没有被摇掉的代码。
- 常见优化包括路由懒加载、组件懒加载、manualChunks、按需引入、替换重依赖、移除无用 polyfill。
- 还要结合网络瀑布、首屏性能和缓存策略判断优化是否真的有效。
- 优化不能只看 gzip 后大小，也要考虑解析和执行 JavaScript 的成本。
题目解析
bundle 分析不是为了追求数字好看，而是为了知道用户首屏到底下载、解析、执行了什么。体积大只是表象，背后可能是依赖选型、拆包策略、公共模块抽取或 Tree Shaking 问题。
优化前要先定位来源。比如图表库全量引入、日期库多语言包、组件库没有按需导入、重复打包两个版本的依赖，处理方式完全不同。
优化后也要复核用户体验。有时拆包让首屏包变小了，但请求变多、点击后等待变长，整体体验未必更好。
代码示例
Vite / Rollup 可以通过可视化插件查看产物组成。
JavaScript
import { visualizer } from 'rollup-plugin-visualizer'
export default {
plugins: [
visualizer({
filename: 'dist/stats.html',
gzipSize: true,
brotliSize: true
})
]
}常见误区
- 没有分析报告就开始改拆包配置，优化方向靠猜。
- 只关注总体积，不看首屏关键路径和 JavaScript 执行成本。
- 拆包过细导致请求瀑布变长，用户点击后等待更多。