Vite生产环境默认代码分割，全链路压测需验证分块是否契合真实流量场景的加载性能与缓存效率；须通过--report分析chunk结构、DevTools观察加载行为，并在压测中结合前端指标评估分块合理性。
Vite 在生产环境默认启用代码分割（code splitting），但全链路压测中验证静态资源分块是否合理，关键不在于“能不能分”，而在于“分得是否符合真实流量场景下的加载性能与缓存效率”。直接跑压测工具打 prod 构建产物，若未关注分块策略与资源加载行为，很容易误判瓶颈在“Vite 配置”，实则问题出在 chunk 划分逻辑或资源引用方式上。
确认构建产物的分块实际输出结构
压测前必须先看清 Vite 究竟生成了哪些 chunk，以及它们的大小、依赖关系和入口归属：
- 运行
vite build --report，生成dist/.vite/rollup-report.json或 HTML 报告，重点看chunks和assets表，识别大 chunk、重复 chunk、非懒加载却被拆出的公共模块 - 检查
dist/assets/下文件名哈希是否稳定（如index.a1b2c3d4.js）、是否含vendor、common、chunk-等标识，确认是否启用了build.rollupOptions.output.manualChunks - 用浏览器 DevTools 的 Network 面板加载首页，过滤 JS，观察初始 HTML 引入了几个 script 标签，哪些是
type="module"，哪些是defer或async，对应到具体 chunk 名称
在压测中观测分块对首屏与关键路径的影响
全链路压测不是只看 QPS 和错误率，要结合前端加载指标反推分块合理性：
- 在压测脚本（如 k6 / JMeter）中模拟真实用户行为：访问首页 → 触发某路由跳转 → 执行某交互操作，同时采集每个步骤的
navigationStart、domContentLoadedEventEnd、loadEventEnd及各 chunk 的fetchStart～responseEnd - 重点关注高并发下“相同 chunk 被重复请求多次”现象——若多个页面共用的
vendorchunk 没有正确提取或未命中强缓存（缺少Cache-Control: public, max-age=31536000），CDN 或浏览器会反复拉取，造成带宽浪费与 TTFB 上升 - 对比不同分块策略下的
Time to Interactive (TTI)：比如将 UI 组件库（如 Element Plus）单独打成ui.***.js，和它被塞进index.***.js对比，看首屏可交互时间是否下降、JS 执行耗时是否更分散
验证分块是否适配 HTTP/2 多路复用与缓存粒度
Vite 默认产出 ESM，配合现代 CDN 和 HTTP/2，分块太细或太粗都会降低收益：
- 若大量小 chunk（manualChunks 将
lodash-es、mitt、qs归入utils - 若某个 chunk 同时被 PC 端和移动端页面引用，但其中仅 20% 代码被移动端使用，却因共用 chunk 导致移动端多载 80% 冗余 JS——这时应按页面维度拆分（
entry: { 'pc-home': 'src/pc/home.ts', 'mobile-list': 'src/mobile/list.ts' }），而非全局提取 vendor - 检查响应头：
index.html应设max-age=0, must-revalidate，而所有.js/.css文件需带长期哈希 +public, max-age=31536000，否则压测中缓存失效会导致分块优化归零
用真实日志+RUM 数据交叉验证
实验室压测只能模拟，真实分块效果要看线上 RUM（Real User Monitoring）：
- 在构建时注入
__vite__chunkMap全局对象（通过transformIndexHtml插件），记录每个页面加载了哪些 chunk 及其 size、duration - 结合压测期间上报的 RUM 数据（如 Sentry Web Vitals、Cloudflare Web Analytics），筛选高 PV 页面，统计各 chunk 的平均加载失败率、慢加载（>2s）占比、与 LCP 元素的关联性
- 若发现某
chunk-xxx.js在 30% 的首屏中加载耗时 >1.5s，且该 chunk 包含一个非关键的图表库，说明它不该出现在初始加载链路中——需改用defineAsyncComponent或import()延迟加载
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
