Vite启动快、HMR快，核心在于开发环境不打包，直接基于浏览器原生ESM按需编译；生产环境则用Rollup打包优化。依赖通过esbuild预构建为ESM并缓存，兼顾兼容性与加载性能。
Vite 的核心优势不在“多快”，而在“怎么快”——它把开发阶段的打包逻辑从“全量预编译”转向“按需动态响应”，这是和 Webpack 本质不同的工程范式。
为什么 Vite 启动快、HMR 快？关键在环境分离
开发环境不打包，生产环境才打包。浏览器原生支持 ES Module，Vite 就直接让浏览器发起 import 请求，比如访问 /src/main.js，它发现里面有 import { createApp } from 'vue'，就自动请求 /@modules/vue.js —— Vite 开发服务器只是拦截这些请求，实时转译（TS→JS、Vue SFC→JS）、返回 ESM 模块，不做任何 bundling。
Webpack 则相反：启动前必须分析全部依赖、递归构建整个 bundle 图，项目越大，分析+打包耗时越长。
- 冷启动：Vite 启动是毫秒级，因为只做初始化服务，不编译源码
- HMR 更新：改一个
.vue文件，Vite 只重编译该组件 + 触发其 HMR 接口，不牵连父组件或工具链 - 首次请求慢是已知问题：首屏加载可能触发多个模块请求，但后续缓存即生效
依赖预构建（Optimize Deps）解决什么实际问题？
现代 npm 包大多用 CommonJS（如 lodash、axios），而浏览器只认 ESM；而且一个包常含几十个子模块（如 element-plus），逐个 HTTP 请求会严重拖慢首屏。
Vite 在首次启动时，用 esbuild（Go 写的超快构建器）把所有 node_modules 中的依赖统一转成 ESM 格式，并合并小模块为单个文件，缓存到 node_modules/.vite。之后浏览器只需请求几个预构建后的 JS 文件，大幅减少请求数和解析开销。
- 不预构建 → 浏览器无法加载 CJS，报错
Cannot use import statement outside a module - 不合并 → 一个 UI 库可能引发上百个 HTTP 请求，卡死开发体验
- 缓存机制 → 第二次启动跳过预构建，除非依赖更新或手动
--force
Vite 开发与生产行为为何不同？这不是缺陷，是设计取舍
开发用浏览器原生 ESM，追求响应速度；生产用 Rollup 打包，追求体积压缩、Tree Shaking、代码分割、资源内联等优化能力。两者目标不同，工具链自然不同。
- 开发时支持
import.meta.env、import.meta.hot等仅限 dev 的 API - 生产构建默认启用
minify: 'terser'、assetsInlineLimit、splitChunks等 Rollup 配置项 - 注意：某些插件（如未适配的 Babel 插件）在 dev 和 build 下行为可能不一致，需验证
高频实操题怎么答出亮点？
面试官不只想听定义，更想确认你真用过、调过、踩过坑。
-
代理配置：别只说
server.proxy，要提changeOrigin: true解决跨域 cookie 问题，以及rewrite去掉路径前缀（如/api） -
路径别名：写清楚
resolve.alias是给 vite 解析用的，同时提醒tsconfig.json里也要配compilerOptions.paths，否则 TS 类型检查会报错 -
环境变量：强调只有
VITE_开头的变量才能被注入客户端，.env.production中的NODE_ENV或API_BASE不加前缀就不可见 -
分包优化：除
build.rollupOptions.output.manualChunks外，可补充动态import()+webpackChunkName注释（Vite 兼容）来实现路由级代码分割
真正拉开差距的，不是背熟“ESM”“esbuild”这些词，而是能讲清：为什么选这个方案、它解决了哪个具体卡点、有没有副作用、线上是否验证过效果。
