Vite 5 配置最佳实践
很多团队用 Vite 的方式是：
vite.config.ts里写几行 alias- 装几个插件
- 能跑就行
但在中大型项目（多入口、多环境、monorepo、SSR、组件库共存）里，Vite 配置会直接决定：
- 冷启动与 HMR 体验
- 生产构建速度
- 产物体积与缓存命中
- 线上可排障性（sourcemap/错误定位）
这篇文章不追求“参数大全”，而是给一套可复制的工程化范式：你在 80% 的项目里照着做就能得到稳定收益。
1. 配置的第一原则：先定义构建边界
在写任何配置前，先回答：
- 你的应用有几个入口？（SPA / 多页面 / SSR）
- 你的依赖边界在哪里？（app vs packages vs vendor）
- 你的部署边界在哪里？（静态、Node、Serverless、Edge）
没有边界，配置就会变成“堆参数”。
2. 依赖预构建（optimizeDeps）：让开发服务器稳定
Vite 开发模式下的关键机制是：
- 依赖预构建（esbuild）
- 让依赖以更适合浏览器的方式被加载
2.1 什么时候需要手动 include/exclude？
典型症状：
- 首次启动很慢
- 某些依赖 HMR 异常
- 某些依赖在 dev 下解析失败
实践建议：
- 把“经常被动态 import 的依赖”纳入 include
- 把“在 dev 下会被频繁变化的 workspace 包”排除
3. alias 与路径规范：一致性比灵活性更重要
最佳实践：
- alias 尽量少
- 统一
@/（src）与~/（项目根） - monorepo 包引用使用 workspace 协议或明确入口
原因：alias 过多会造成：
- IDE 跳转与 TS 路径不一致
- 打包产物路径混乱
4. build.rollupOptions：面向“缓存命中”的代码分割
很多项目的 chunk 策略是默认的，结果：
- 一个小改动导致 vendor chunk 变动
- CDN 缓存命中率下降
建议目标：
- app 代码与 vendor 代码尽量分离
- 大依赖单独 chunk（react、vue、editor）
- 业务域 chunk（按路由/按模块）
核心原则：
- 分割不是越细越好
- 分割应该服务缓存命中与并行加载
5. CSS 与资源：不要让样式成为构建瓶颈
- 大型 Tailwind 项目注意 content 扫描范围
- 资源（图片/字体）建议走 CDN，并保持文件名 hash
- 字体与关键图片优先级策略要在应用层配合（preload）
6. 产物分析：没有数据就没有优化
建议在 CI 或本地保留：
- bundle visualizer（查看 chunk 分布）
- 构建耗时统计
- 关键页面的资源 waterfall
目标是回答：
- “体积变大是因为哪个 chunk？”
- “构建变慢是因为哪个阶段？”
7. monorepo 最佳实践：workspace 包的热更新与依赖边界
monorepo 下最常见的问题：
- workspace 包被当成依赖预构建，导致 HMR 不直观
- 或 workspace 包被当成源码，导致 dev watch 压力大
折中策略：
- app 内部包：当源码处理（便于 HMR）
- 大型第三方包：保持 vendor
- 对“变化频繁但体积大”的包，考虑拆分入口
8. 推荐的配置结构（可复制模板）
把配置拆分成三层：
vite.base.ts：共享（alias、define、plugins）vite.dev.ts：开发（server、optimizeDeps）vite.prod.ts：生产（build、rollupOptions、sourcemap）
这样做的好处：
- dev 与 prod 的目标不同，不必在同一文件打补丁
- 可读性强，减少“条件分支地狱”
9. 上线检查清单
- dev 启动时间与 HMR 是否稳定
- 是否有合理的 chunk 策略（vendor/app/域）
- 是否开启产物分析与体积监控
- sourcemap 策略是否符合安全与排障
- monorepo 包的边界是否清晰
总结
Vite 5 配置的最佳实践不是“参数技巧”，而是：
- 定义边界
- 稳定开发体验（optimizeDeps）
- 为缓存命中设计 chunk
- 用可观测性驱动优化
