学Vite要从解决问题出发，拆解启动、编译、打包、运行四环节并逐项验证；先跑通最小项目，再动手改配置，重点练入口控制、资源别名、环境变量注入三类高频配置，构建后必查dist产物。
学 Vite 构建，不能只记配置项，得从“它解决什么问题”出发，把构建流程拆成可验证的环节——启动、编译、打包、运行，每个环节对应一个典型现象，比如改一行代码立刻刷新，说明 HMR 生效；构建后多出 vendor.js，说明 manualChunks 配置起作用。
先跑通一个最小可构建项目
不急于写配置文件。用官方命令初始化，立刻验证构建是否真正发生：
- 执行
npm create vite@latest my-app -- --template vanilla，选最简模板 - 删掉
src/main.js中所有内容，只留console.log('build test') - 运行
npm run build，检查dist/下是否生成index.html和带哈希的 JS 文件 - 用
npx serve -s dist启动静态服务，打开页面看控制台能否打印
动手改配置，每改一项就验证一项
Vite 的配置不是“堆参数”，而是针对具体需求加开关。重点练三类高频配置：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
-
入口控制：多页项目时，在
vite.config.js中设build.rollupOptions.input，指向多个 HTML 文件路径，构建后确认输出目录里有对应数量的 HTML -
资源别名：加
resolve.alias，比如@: path.resolve(__dirname, 'src')，然后在 JS 中写import { utils } from '@/utils'，保存后看 HMR 是否正常触发 -
环境变量注入：在
.env.production写VITE_API_URL=https://api.example.com，代码中访问import.meta.env.VITE_API_URL，构建后检查dist中 JS 是否已替换成实际值
直面构建产物，养成“看 dist”的习惯
构建不是黑盒。每次 npm run build 后，必须打开 dist 目录手动检查：
- HTML 中 script 标签的
src路径是否正确（尤其注意 base 配置影响） - JS 文件是否被自动分割（如
import()触发的 chunk 是否独立存在） - CSS 是否提取为单独文件（
build.cssCodeSplit默认开启） - 体积异常大的 JS 文件，用
rollup-plugin-visualizer插件查来源
卡点排查要锁定现象，反推原因
遇到问题，先观察浏览器控制台和终端输出，再缩小范围：
- 页面白屏 → 查 network 面板有没有 404，重点看 main.js 或 index.html 加载失败
- HMR 不生效 → 确认修改的是当前页面关联的模块，不是 node_modules 或 public 下文件
- 样式丢失 → 检查 CSS 是否被错误地内联进 HTML（
build.rollupOptions.output.inlineDynamicImports可能误开） - 环境变量未注入 → 确认变量名以
VITE_开头，且未在.env.local中被覆盖
