[!info] related notes

• 所属：构建与优化 MOC
• 前置：代码分割 · 生产构建

Vite 构建分析与优化

这个概念为什么出现

“感觉包很大”不能指导决策。必须看见 chunk 组成，才能判断：路由拆分、换轻量库、还是接受成本。

[!abstract] 一句话理解 优化顺序：测量 → 定位影响目标页面的依赖 → 改依赖/拆分 → 再测量。

实践步骤

1. pnpm build 观察输出体积
2. 接入与当前 Vite / Rolldown 版本兼容的 visualizer 类插件生成 treemap，核对插件 peerDependencies 与支持说明
3. 对最大依赖提问：首屏需要吗？可否动态 import？
4. 验证功能与缓存哈希

分别记录未压缩产物、gzip/Brotli 传输大小与目标页面的实际请求。treemap 面积不能直接代表下载耗时或执行成本；还要检查首屏依赖、预加载、缓存命中及运行时解析/执行。比较时固定构建模式与压缩策略。

常见收益点

• 图表/编辑器/管理页异步化
• 重复工具库去重
• 图片与字体不进 JS 误打包

本节总结

没有测量的优化是随机重构；构建分析是门禁不是装饰。

自测题

1. 为什么先拆路由再谈微前端？

参考答案

路由级拆分成本低、收益直接；微前端是架构级复杂度，不应作为体积问题的第一反应。