容器预热预跳转方案

代码

业务场景：商品详情页 → 下单填写页 高概率预跳转，缩短首帧耗时 技术栈：Webpack5 + Vue3（Vue2/React 只需要修改组件渲染部分）

一、安装依赖

npm i webpack webpack-cli html-webpack-plugin webpack-route-manifest css-loader style-loader vue-loader vue-style-loader -D npm i vue

二、目录结构参考

src ├─ router.js # 路由配置 ├─ preWarmFillOrder.js # 预加载+预热核心逻辑 ├─ views │ ├─ detail │ │ └─ index.vue # 商品详情页 │ └─ fill-order │ └─ index.vue # 目标：下单填写页 └─ main.js dist # 打包输出目录（自动生成） index.html webpack.config.js

三、webpack.config.js 完整配置

const path = require('path') const HtmlWebpackPlugin = require('html-webpack-plugin') const RouteManifest = require('webpack-route-manifest') const { VueLoaderPlugin } = require('vue-loader') module.exports = { entry: './src/main.js', output: { path: path.resolve(__dirname, 'dist'), filename: 'assets/[name].[contenthash].js', chunkFilename: 'assets/[name].[contenthash].js', clean: true }, module: { rules: [ { test: /\.vue$/, loader: 'vue-loader' }, { test: /\.css$/, use: ['style-loader', 'css-loader'] } ] }, plugins: [ new HtmlWebpackPlugin({ template: './index.html' }), new VueLoaderPlugin(), new RouteManifest({ // ✅ 核心：自动识别fill-order模块，映射路由 routes(modulePath) { if (modulePath.includes('fill-order')) { return '/fill-order' } return null }, filename: 'route-manifest.json', base: '/', inline: false // 不自动内联到window，我们直接fetch文件 }) ], optimization: { splitChunks: { chunks: 'all' // 自动抽取公共vendor、runtime chunk } } }

四、路由配置 src/router.js

⚠️ 必须写魔法注释/* webpackChunkName: "fill-order" */，插件靠这个识别模块

import { createRouter, createWebHistory } from 'vue-router' const routes = [ { path: '/detail', component: () => import('@/views/detail/index.vue') }, { path: '/fill-order', component: () => import(/* webpackChunkName: "fill-order" */ '@/views/fill-order/index.vue') } ] const router = createRouter({ history: createWebHistory(), routes }) export default router

五、核心预加载 & 预热文件 src/preWarmFillOrder.js

let routeManifestCache = null let preWarmedInstance = null let preWarmedContainer = null const TARGET_ROUTE = '/fill-order' /** * 读取route-manifest.json，生成link preload预拉资源 */ async function preloadRouteAssets() { if (routeManifestCache === null) { const res = await fetch('/route-manifest.json') routeManifestCache = await res.json() } const assets = routeManifestCache[TARGET_ROUTE] || [] assets.forEach(item => { // 防止重复生成link if (document.querySelector(`link[href="${item.href}"]`)) return const link = document.createElement('link') link.href = item.href if (item.type === 'js') { link.rel = 'preload' link.as = 'script' link.crossOrigin = 'anonymous' } else if (item.type === 'css') { link.rel = 'preload' link.as = 'style' } document.head.appendChild(link) }) } /** * 浏览器空闲时机，后台预热组件实例 * 弱网自动降级不预热 */ export async function warmUpFillPage() { // 已经预热，直接返回 if (preWarmedInstance) return // 弱网环境直接跳过 if (navigator.connection && ['2g', '3g', 'slow-2g'].includes(navigator.connection.effectiveType)) { return } await preloadRouteAssets() requestIdleCallback(async () => { try { //只有路由必须加魔法注释，这里是让webpack不要重复打包一份，复用 //动态import没有语法糖，组件导出挂在default上 const { default: FillOrderPage } = await import(/* webpackChunkName: "fill-order" */ '@/views/fill-order/index.vue') const { createVNode, render } = await import('vue') // 创建隐藏容器 preWarmedContainer = document.createElement('div') preWarmedContainer.style.display = 'none' //先塞进body执行组件初始化、生命周期、渲染 document.body.appendChild(preWarmedContainer) // 实例化组件 const vnode = createVNode(FillOrderPage) render(vnode, preWarmedContainer) preWarmedInstance = vnode } catch (err) { console.error('填写页预热失败：', err) } }) } /** * 跳转入口：优先复用预热好的实例，兜底正常路由跳转 * @param {Function} originPush router.push */ export function jumpToFill(originPush) { if (preWarmedInstance && preWarmedContainer) { const realRouterView = document.querySelector('#router-view') //替换路由页面，换成预热好的 realRouterView.replaceChildren(preWarmedContainer) preWarmedContainer.style.display = '' // 清空标记，避免异常复用，这里只是清空引用，节点还在，清除节点调用clearPreWarm preWarmedInstance = null preWarmedContainer = null return } originPush(TARGET_ROUTE) } /** * 页面卸载时清理预热实例，防止内存泄漏 */ export function clearPreWarm() { if (preWarmedContainer) { preWarmedContainer.remove() } preWarmedInstance = null preWarmedContainer = null }

六、商品详情页 src/views/detail/index.vue

<template> <div class="detail-page"> <h3>商品详情</h3> <button id="goFillBtn">去下单填写</button> </div> </template> <script setup> import { onUnmounted } from 'vue' import { warmUpFillPage, jumpToFill, clearPreWarm } from '@/preWarmFillOrder' import { useRouter } from 'vue' const router = useRouter() const goFillBtn = document.querySelector('#goFillBtn') // ✅ 预判触发：鼠标悬浮按钮开始预热（可改成曝光/停留计时） goFillBtn?.addEventListener('mouseenter', () => { warmUpFillPage() }, { once: true }) // 点击跳转 goFillBtn?.addEventListener('click', () => { jumpToFill(router.push) }) // 离开页面销毁预热资源 onUnmounted(() => { clearPreWarm() }) </script>

七、目标填写页 src/views/fill-order/index.vue

<template> <div class="fill-page"> <h3>下单填写页</h3> <p>订单表单区域</p> </div> </template>

八、入口 html index.html

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>预跳转demo</title> </head> <body> <div id="router-view"></div> </body> </html>

九、入口 main.js

import { createApp } from 'vue' import router from './router' import App from './App.vue' const app = createApp(App) app.use(router) app.mount('#router-view')

十、Nginx / CDN 关键配置（重要！）

route-manifest.json不能强缓存，否则发布后一直读取旧 hash 清单

location /route-manifest.json { add_header Cache-Control no-cache; }

十一、打包后 dist/route-manifest.json 输出样例

{ "/fill-order": [ {"type":"js","href":"assets/fill-order.28a7bc12.js"}, {"type":"js","href":"assets/vendor.88f2ac31.js"}, {"type":"css","href":"assets/fill-order.28a7bc12.css"} ], "*": [ {"type":"js","href":"assets/runtime.66ac221.js"} ] }

十二、Vue2 / React 修改说明

1. Vue2：替换createVNode/render为new Vue()挂载隐藏容器
2. React：预热部分改用createRoot(container).render(<FillOrder />)

十三、注意事项清单

1. 预热阶段不要请求实时库存、价格等强一致性数据，跳转后再拉
2. requestIdleCallback兼容性：低版本浏览器会直接不执行预热，自动降级
3. 不要大量页面同时预热，只用于下单、秒杀等高概率跳转场景
4. 开发环境 dev 模式不需要这套预热逻辑，仅生产打包使用

十四、面试问题

下单 / 秒杀等高概率跳转场景，使用link-preload预加载目标页面 chunk，结合浏览器空闲时机做容器预热预跳转，优化后首帧等待缩短约 160ms。

面试高频问题 + 参考答案（附带追问预判）

1. 为什么选 link-preload，而不是 prefetch /preconnect？

答：

• preload：高优先级、当前页面立刻请求资源，适合确定大概率马上要用的核心 chunk（秒杀 / 下单这种高概率跳转）；
• prefetch：低优先级，浏览器空闲才拉，适合未来可能访问、但不确定马上用的资源；
• preconnect：只提前建立连接，不下载资源，缺少 chunk 内容。 本场景是高概率即将跳转，需要尽快拿到页面代码，所以 preload 更合适。

✅ 面试官大概率追问：preload 会不会抢占当前页面带宽、影响现有交互？

补充回答：会，所以要加判断，只在页面空闲、无关键交互、网络良好时才触发 preload，不能无脑加载。

2. “浏览器空闲时机” 你用什么 API 判断？为什么不用 setTimeout？

答：使用requestIdleCallback，它由浏览器调度，在主线程空闲时段执行预热逻辑；setTimeout 只是宏任务，不能感知浏览器真实空闲，容易抢占主线程造成卡顿。

✅ 追问：requestIdleCallback 兼容性不好怎么办？

补充：做降级，优先使用 rIC，不支持就用低延迟 setTimeout 兜底，同时增加判断：页面无滚动、无点击、网络不弱才执行。

3. 什么是容器预热预跳转？具体做了哪些事？

答：预加载拿到目标 chunk 后，空闲时机提前初始化路由容器、预实例组件、预请求基础接口、预渲染骨架，但不展示页面；用户真正点击跳转时，直接挂载渲染，省去初始化 + 资源解析耗时，也就是这 160ms 的主要收益来源。

✅ 追问：预热会不会额外消耗内存？怎么控制？

补充：有过期策略，长时间未触发真实跳转就销毁预实例、清空缓存；同时限制同时预热页面数量，避免内存堆积。

4. 怎么判断 “高概率跳转场景”？阈值怎么定？

答：两种判定：①业务硬标记（下单按钮、秒杀弹窗这类固定高转化入口）；②行为埋点预判（用户停留该按钮区域、鼠标悬停、多次滚动到模块），满足条件才开启预逻辑，低概率场景不预加载，避免浪费带宽和内存。

✅ 追问：如果用户预加载之后又不跳转，资源不就浪费了？

补充：资源本身会进浏览器缓存，后续再访问仍然复用；同时非强业务场景降低预触发条件，不盲目预加载。

5. 160ms 这个指标怎么统计出来的？怎么验证优化效果？

答：通过性能指标采集，对比点击跳转 -> 目标页面首帧渲染的时间差值，统计大量样本得到平均缩短 160ms；使用 Performance、web-vitals 采集 LCP、跳转交互耗时，做 AB 实验区分实验组和对照组。

✅ 追问：有没有可能个别场景反而变慢？

补充：弱网、主线程繁忙时直接关闭预逻辑，增加前置判断，劣环境下不执行预加载，防止和现有资源争抢。

6. 和普通的页面预取、路由预加载有什么本质区别？

答：普通预取只下载 js 资源；这套方案是资源预下载 + 空闲时机容器 & 组件预实例化，不止把文件拿到本地，提前做完页面初始化工作，核心耗时提前消化。

7. 有没有坑？生产遇到过什么问题？

答：

1. preload 重复请求 chunk：配合 webpack/vite 的资源标识，避免重复 link 标签；
2. 预渲染时请求接口污染数据：预热接口加标记，不更新真实业务状态；
3. 路由状态冲突：预实例隔离，真实跳转时销毁预实例再挂载正式实例；
4. 移动端弱网下预加载拖慢页面：网络判断 navigator.connection，2g/3g 直接禁用。

8. 如果改成低概率页面跳转，你会调整方案吗？

答：会，换成 prefetch 代替 preload，取消组件预热，只后台静默下载资源，不占用主线程做实例化。

9.文件 chunkhash 命名，内容变了名字就变了，怎么确保引用正确

webpack 输出带[contenthash]的 chunk，文件名称会随文件内容变化而改变，不能硬编码静态资源地址，方案核心就是通过 manifest 清单映射路由和对应的真实哈希文件名，也就是我们代码里用到的route-manifest.json。

1. 构建阶段：webpack-route-manifest插件会收集路由对应的所有 chunk（js/css）的最终哈希后的真实路径，输出一份清单route-manifest.json。
2. 运行阶段：前端先拉取这份清单，通过路由/fill-order查到当前对应的真实xxx.[contenthash].js地址，再动态生成 preload link，不会写死文件名。
3. 缓存兜底：html 文件本身也会经过 html-webpack-plugin 处理，html 里引入的资源也会自动替换 contenthash 地址；浏览器依靠 contenthash 实现长效缓存，文件不变哈希不变，直接复用缓存。

✅ 面试官高频追问 1：如果不用第三方插件 webpack-route-manifest，原生 webpack 怎么实现？ 答：可以使用 webpack 内置的manifest插件（webpack-manifest-plugin），它会输出所有资源映射表，key 是原始 chunk 名（fill-order.js），value 是带 contenthash 的真实文件名。我们自己做一层映射：路由 → chunkName → manifest 获取真实资源地址，逻辑和现在一致，只是需要自己维护路由和 chunk 的关联关系，不像webpack-route-manifest可以直接绑定路由。

✅ 面试官高频追问 2：route-manifest.json 本身要不要加 hash？如果清单缓存旧了怎么办？ 答：route-manifest.json建议不长期强缓存，设置协商缓存（ETag/Last-Modified）；也可以给清单文件名增加 hash。 风险点：如果清单被浏览器长时间缓存，拿到旧的资源地址会 404。所以不能设置Cache-Control: max-age=31536000这类永久缓存，优先协商缓存，构建发布更新后能及时拿到最新清单。

✅ 面试官高频追问 3：预加载的 js 资源，preload 成功后，后续路由 import 的时候会不会重复请求？ 答：不会。浏览器层面缓存了资源，import()发起请求时命中内存 / 磁盘缓存，直接复用。 补充：但要保证资源 href 完全一致，清单输出的路径和 webpack 打包输出、import 加载的路径必须完全相同，一旦路径有差异会二次请求。

✅ 面试官高频追问 4：contenthash、chunkhash、hash 三者区别？

• hash：整个项目构建一次，全部文件共用同一个 hash，任意文件改动，所有 hash 都变（不推荐）
• chunkhash：同一个 chunk 内的文件共用 hash，同 chunk 只要有文件改动，该 chunk 所有资源 hash 都会变
• contenthash：文件本身内容单独生成 hash，只有当前文件内容改动，自身 hash 才变化，独立缓存，是我们这个场景最优选择

✅ 面试官高频追问 5：生产如果 route-manifest.json 加载失败，降级方案是什么？ 答：降级到常规动态 import，不再做 preload 资源预拉，只保留普通路由懒加载，页面功能不受影响，只是失去预优化收益，代码里可以捕获 fetch 异常直接跳过预加载逻辑。

一、核心预热渲染逻辑相关（最高频）

1. 问：你这里用createVNode + render直接渲染隐藏 div 做预热，和直接import拿到组件不渲染有什么区别？

回答只import仅仅是下载、解析 js，编译组件选项；createVNode + render会执行 setup、生命周期钩子、模板编译、响应式初始化、计算属性、watch，把大量耗时提前做完，这才是 160ms 收益核心。只 import 达不到这个效果。 ✅ 追问：预热时接口请求、定时器、事件监听会执行吗？会不会污染？

回答：会！onMounted 等生命周期会直接执行。 坑：如果页面一挂载就请求接口，预热阶段就会提前发请求，可能产生无效请求、脏数据。 解决方案：增加环境标记，全局挂载一个变量app.config.globalProperties.__PRE_WARM__ = true，组件直接读这个全局变量（简单直接，注意全局变量冲突），组件内判断如果是预热环境，跳过非必要接口 / 定时器 / 埋点。

2. 问：preWarmedContainer直接 replaceChildren 替换 #router-view，这种方案有没有缺陷？

回答优点：速度最快，跳过路由内部组件实例化流程。 缺陷：

1. 破坏 vue-router 内部实例、路由守卫、滚动记忆、路由元信息，$route 相关状态不是路由原生驱动；
2. 浏览器回退、多次跳转时容易出现 DOM 和路由状态不同步；
3. 如果目标页面依赖路由参数（query/params），当前方案没有传入参数，直接渲染会异常。 ✅ 追问：那更好的方案是什么？

方案 A（稳妥）：不直接替换 DOM，预实例组件但不挂载，真正跳转时走正常 router.push，在组件内部复用已经实例好的 vnode / 数据； 方案 B：预启动路由实例，push 预路由，路由内部 keep-alive 缓存，这是更标准方案。

3. 问：requestIdleCallback的问题？空闲时机如果一直不来怎么办？

回答rIC 只有主线程空闲才执行，如果页面持续滚动、动画、大量任务，回调永远不触发，预热失效。 ✅ 追问：兜底策略？

双层兜底：设置超时，setTimeout兜底触发预热；同时增加判断：页面无滚动、无点击、无长任务才执行。 补充：requestIdleCallbacksafari 兼容性差。

二、内存泄漏 & 资源清理类（必问）

4. 问：什么时候会触发clearPreWarm？如果忘记清理会有什么问题？

回答页面离开详情页、组件卸载、路由切换时调用 clearPreWarm。 不清理的问题：隐藏 div 留在 body 里，组件实例、定时器、订阅、事件监听、全局 watch 持续持有引用，内存持续上涨，移动端长时间页面卡顿。 ✅ 追问：除了 remove 节点，还需要手动销毁 vnode 吗？

回答：最好手动render(null, preWarmedContainer)卸载 vnode，触发组件 onUnmounted，清除响应式订阅、定时器，单纯 remove dom 节点 vue 的副作用不一定清理干净。

三、preload、route-manifest 资源相关

5. 问：preload 只是提前加载资源，浏览器会不会优先执行这个 js？会不会抢占主线程？

回答link preload只是下载资源，不会自动执行 js，只是放到缓存；真正执行是后面 import 的时候。 ✅ 追问：高优先级 preload 会不会抢占首屏资源带宽？

回答：所以加了前置判断：弱网不预热；只在高概率场景（鼠标悬浮下单按钮）才开启，低概率不预加载。

6. 问：route-manifest 里的资源顺序有没有影响？css 和 js preload 顺序问题？

回答有。如果 css 晚加载，页面出现闪屏 FOUC；清单要保证 css 资源优先。 ✅ 追问：preload css 会不会阻塞渲染？

preload 只是预拉，不会阻塞当前页面渲染；等真实页面挂载时 css 已经就绪。

7. 问：同一个资源多次 preload，你做了 query 选择器去重，有没有漏洞？

回答当前判断document.querySelector(\link [href="${item.href}"]`)` 可以防止重复创建 link。 漏洞：资源加载中（pending 状态）还没生成 link 标签时，并发多次调用 warmUpFillPage，会重复添加 link。

优化：增加 pending 锁（变量标记正在预加载中）。

四、Webpack & 魔法注释相关

8. 问：代码里两处/* webpackChunkName: "fill-order" */，两处都写的意义？能不能只写一处？

回答router 里的 import 是路由懒加载标记；warmUp 里的 import 如果不加注释，webpack 会生成第二个独立 chunk（名字随机），两份代码打包，资源重复。 两处一致魔法注释，webpack 会复用同一个 chunk。 ✅ 追问：如果两个 import 魔法注释不一致会发生什么？

会打包两份独立 chunk，preload 预拉的是 A chunk，真实路由加载 B chunk，缓存失效，双倍流量。

9. 问：splitChunks 配置只有 chunks:'all'，有没有潜在问题？

回答会自动拆分公共包，但如果 fill-order 页面依赖大量公共 vendor，route-manifest 能不能收集到依赖的公共 chunk？

webpack-route-manifest 默认会收集该路由触发加载的所有关联 chunk（包含 split 出来的 vendor），但部分版本插件有坑，漏收集公共 chunk，导致 preload 缺少公共 js。

五、边界场景、异常、降级

10. 问：用户预热之后很久才点击跳转，这时资源缓存过期、或者已经发布新版本，会出现什么问题？

回答清单是旧的，preload 了旧 hash 资源，新构建后代码不匹配，可能报运行时 js 报错。

✅ 追问：怎么解决？

增加预热有效期，比如预热 5s/10s 内未点击，自动销毁预实例，失效丢弃；新版本发布后不使用旧预热实例。

✅ 追问：那预热是否失效？

设置 10s 有效期自动销毁预实例，不是预热彻底没用了：

1. 大部分用户行为是短时间内点击（悬浮按钮、马上提交下单），10s 窗口足够覆盖绝大多数有效场景，能拿到 160ms 的提速收益；
2. 超过 10s 还没点击，属于低概率即时跳转，这时旧预实例风险＞收益，主动销毁规避新旧代码不兼容的 JS 报错；
3. 如果用户超时之后再次产生高概率行为（比如重新 hover 下单按钮、再次滚动到该区域），我们会重新触发warmUpFillPage，重新拉最新 manifest、重新预热实例。

✅ 面试官继续追问：那如果用户刚好第 11s 点击，就失去预热收益了，能不能不直接销毁预实例，做别的方案？

答：可以分层方案，二选一，优先讲版本校验方案（更高级，加分）方案 A（简单方案，前面说的时效销毁）：定时销毁 + 可重新触发，实现简单，适合大多数业务。 方案 B（进阶方案，不直接销毁实例，先校验版本）

• 预加载的时候，缓存manifest 的版本标识（比如构建时间、build hash）；
• 用户点击跳转前，先快速请求一次极简版本接口 / 直接轻量 fetch 最新 route-manifest 的 ETag；
• 如果版本没变：继续复用现有预实例；
• 如果版本已更新：丢弃旧实例，走正常路由跳转（或者同步新资源再跳转）

优势：不用硬 10s 过期，版本没变的情况下哪怕隔很久依然能复用预热，只有发布新版本才作废。 缺点：点击时多一次极轻量网络校验，会增加一点点耗时。

✅ 再追问：manifest 本身怎么带上版本？

答两种实现：

1. 构建时在 route-manifest.json 里额外注入buildId（打包时间 / CI 构建编号）；
2. 利用 http 缓存：请求 manifest 后保存ETag/Last-Modified，点击时用If-None-Match做 304 校验，不用下载完整清单。

✅ 再追问：还有没有更极致的方案，既不丢预热、又不怕版本更新？

答：可以资源预缓存，但不提前实例化组件：

• 高概率场景只做 preload 资源（下载 chunk 进浏览器缓存），不执行 createVNode 渲染实例；
• 资源本身依靠浏览器协商缓存，就算隔很久点击，浏览器会校验资源是否最新；
• 真正点击的瞬间，再去实例组件。

缺点：只能省资源下载时间，没法拿到组件提前初始化、setup 执行的 160ms 核心收益，收益降级。

✅ 再追问：线上你实际选型会用哪种？

答业务优先选择【时效过期 + 可重新触发预热】： 下单、秒杀属于即时转化场景，用户大概率短时间内点击，10s 窗口足够覆盖绝大多数流量；实现简单稳定，不需要额外版本接口，风险可控； 如果是后台、长停留页面这种用户可能长时间停留再跳转的场景，会升级成【buildId 版本校验方案】。

11. 问：如果目标页面有 keep-alive，这套预热逻辑和 keep-alive 冲突吗？

回答冲突。keep-alive 由 vue-router 管理缓存实例，我们自己手动创建 vnode 替换 DOM，脱离 keep-alive 体系，缓存失效。

12. 问：多 tab、快速多次点击预热入口，怎么防止并发多次预热？

回答当前代码只有if(preWarmedInstance) return，没有 “正在预热” 的锁。 比如快速连续触发 warmUpFillPage，会并发多次 fetch manifest、多次 import 组件，造成重复请求。

需要增加isWarmingpending 锁。

六、架构 & 选型对比拔高题（面试官区分度高）

13. 问：同样做路由预加载，为什么不用 vue-router 的 prefetch / 第三方库，自己手写这套？

回答vue-router 内置 prefetch 只能预拉资源，不能提前实例化组件、执行 setup 生命周期，没有我们这份 160ms 的收益； 同时内置 prefetch 缺少细粒度控制（无法区分弱网、空闲时机、高概率触发），灵活性不足。

14. 问：如果换成 Vue3 + Vite，这套方案需要改动哪些地方？

回答

1. vite 没有 webpackChunkName 魔法注释，用import(/* @vite-ignore */)或者rollup分块命名；
2. 没有 webpack-route-manifest 插件，需要自己基于 vite 插件收集路由和 chunk 映射；
3. 底层createVNode/renderAPI 不变，但 vite 预构建、依赖预加载逻辑不一样。

七、性能指标与灰度

15. 问：160ms 这个耗时是哪一段省下来的？能不能拆解？

回答常规链路：点击 → import 加载 chunk → js 解析编译 → 创建 vnode → 执行 setup / 生命周期 → 渲染 DOM 预热链路：提前完成【下载 + 解析编译 + vnode 创建 + setup 执行】 点击时只剩 DOM 挂载，节省的就是这一段合计约 160ms。 ✅ 追问：怎么监控预热有没有生效？

埋点上报两个指标：命中预热实例的占比、预热成功 / 失败率、跳转 LCP 差值，做 AB 实验。

16.具体埋点算出 160ms 收益是怎么做的

核心一句话：做 AB 实验，分别采集【正常跳转链路】和【命中预热链路】从 “用户点击” 到 “目标页面首帧可渲染完成” 的耗时，两组均值差值就是约 160ms 收益。

<script setup> const props = defineProps({ isPreWarm: { type: Boolean, default: false } }) onMounted(() => { //直接计算差值上报 const cost = performance.now() - window.__jump_click_ts //辅助字段也要上报，后端要做数据清洗，比如弱网什么的 report({ event: 'fill_order_jump_cost', isPreWarmHit: props.isPreWarm, cost, // 下面这些是过滤用的维度 effectiveType: navigator.connection?.effectiveType, // 网络类型 2g/3g/4g/wifi isOnline: navigator.onLine, // 是否离线 // 页面是否后台休眠 wasHidden: document.visibilityState === 'hidden', // 跳转开始时间（时间戳，用来判断长时间停留） jumpStartTs: route.state.clickTs, // 当前页面已经打开多久 pageLiveTime: performance.now(), // 标记：用户是否中途离开页面 jumpCancel: false, // 设备/内存信息（可选） deviceMemory: navigator.deviceMemory, hardwareConcurrency: navigator.hardwareConcurrency }) }) </script>

数据过滤（非常关键，面试容易问）

原始埋点数据要清洗，剔除异常样本：

1. 剔除弱网、离线、长时间后台休眠的样本
2. 剔除点击后快速切页面、取消跳转的无效样本
3. 剔除页面长时间停留、页面内存过载、浏览器冻结的异常耗时
4. 排除路由参数不同、接口耗时差异大的干扰样本 最后取有效样本的平均值，实验组命中预热均值 - 对照组均值 ≈160ms

AB 实验设计

• 对照组：全量关闭预热，正常动态 import 加载页面
• 实验组：开启预热逻辑，自动标记是否命中预实例

不能直接拿实验组 “命中预热” 和 “没命中预热” 对比（存在选择偏差：命中预热本身就是页面空闲、网络好的优质环境），必须独立对照组。

✅ 面试官高频追问

追问 1：怎么精准判断这次跳转【真的复用了预热实例】？

答：jumpToFill函数里，走到复用预实例分支时，提前打标记window.__isPreWarmHit = true，传给目标页面，埋点带上这个标识。只有真正走到 DOM 替换分支才算命中；预热成功但超时销毁、没复用的不算。

追问 2：会不会出现统计虚高？比如刚好当时浏览器空闲，本来就快，不是预热带来的？

答：这就是为什么要 AB 分流，用户随机分到对照组 / 实验组，抹平浏览器、网络、设备、页面负载等干扰变量；同时可以增加分层统计：区分高端机 / 低端机、4G/WiFi，看收益是否稳定。

追问 3：除了平均耗时，还会看什么指标？

答：

1. P50/P95 耗时（不能只看均值，重点关注慢用户体验）
2. 预热命中率：触发预热后真正被用户点击复用的比例
3. 预热失败率：预加载 / 实例化报错比例
4. 异常报错率：复用预实例后 JS 报错、页面白屏比例

追问 4：能不能用 web-vitals 来统计？

答：可以辅助参考 LCP、INP，但不做主指标。 INP 衡量交互延迟，LCP 衡量最大内容渲染；预热优化的是路由切换 + 组件初始化这一段，属于路由交互中间环节，自定义打点会更精准。

追问 5：如果上线后，部分用户收益达不到 160ms，甚至没收益怎么排查？

答：先看埋点：

1. 预热命中率是不是很低（大部分预热超时失效）
2. 很多命中预热的样本里，页面还有大量同步接口阻塞渲染
3. 低端设备 JS 解析本身瓶颈大，收益会波动

可直接口述精简版（面试口述）

针对下单、秒杀等高概率跳转场景，我们用 link-preload 优先预拉目标页面 chunk，通过 requestIdleCallback 在浏览器空闲的时候提前初始化路由容器、预实例组件做页面预热，而不是等用户点击后再加载初始化。真实点击跳转时直接挂载渲染，省去资源解析和初始化开销，统计下来首帧等待大概缩短 160ms。同时增加环境判断，弱网、主线程繁忙时关闭预逻辑，也有超时销毁预实例的策略，控制带宽和内存开销。