页面切换卡顿主因是DOM批量重绘与样式重排，而非网络延迟；需禁用CSS过渡动画、手动清理节点、避免同步DOM操作，并通过堆快照排查内存泄漏及分包优化加载性能。

页面切换卡顿是因为路由动画或 DOM 批量重绘？

多数 HTML5 单页应用（SPA）在切换页面时卡顿，并非网络慢，而是 router-view 或 ng-view 切换瞬间触发大量 DOM 重建 + 样式重排（reflow）+ JavaScript 同步执行。尤其在低端安卓 WebView 或 iOS Safari 中，transition 动画叠加 innerHTML 替换，极易掉帧。

实操建议：

• 禁用页面级 CSS 过渡动画（如 .page-enter, .page-leave），改用 transform: translateX() + will-change: transform，避免触发布局计算
• 切换前手动调用 document.querySelector('.page-current').remove()，而非依赖框架自动卸载，防止旧节点残留引发重绘
• 避免在 beforeRouteEnter（Vue）或 ngOnInit（Angular）中同步执行 DOM 操作或大量 querySelectorAll

Vue Router / React Router 切换时内存泄漏怎么查？

卡顿持续加重、多次切换后页面响应变慢，大概率是组件未正确销毁导致事件监听器、定时器、IntersectionObserver 实例堆积。Vue 的 beforeDestroy 或 React 的 useEffect cleanup 被忽略是最常见原因。

实操建议：

• Chrome DevTools → Memory → “Take heap snapshot”，切换两次页面后拍第二张快照，筛选 Detached DOM tree，看是否有未释放的 div 或 canvas 节点
• 检查是否在 mounted 或 useEffect 中写了 window.addEventListener('scroll', handler) 却没在卸载时 removeEventListener
• 用 performance.mark() + performance.measure() 包裹路由守卫逻辑，确认耗时是否集中在 created 阶段（说明初始化逻辑过重）

首屏之后的页面切换仍慢？检查 Webpack 分包和懒加载粒度

很多项目只做了 import(/* webpackChunkName: "page-a" */ './PageA.vue')，但没注意组件内部是否引入了巨型依赖（比如全量 echarts、pdfjs-dist）。每次切换都触发新 chunk 加载 + 执行，JS 解析时间直接拉高 TTFB（Time to First Byte）后的阻塞时长。

实操建议：

• 运行 npx webpack-bundle-analyzer dist/stats.json，确认每个路由 chunk 是否含非必要模块；把 echarts 改为按需加载：import('echarts/lib/chart/bar')
• 对非首屏必需的组件（如弹窗、富文本编辑器）使用 defineAsyncComponent（Vue 3）或 React.lazy + Suspense，并加 fallback 避免白屏假死
• 禁用 prefetch：Webpack 默认开启 /* webpackPrefetch: true */，会在空闲时预加载所有路由 chunk，反而挤占主线程资源；改为显式控制：import(/* webpackPreload: true */ './CriticalModule.js')

const router = createRouter({
  routes: [
    {
      path: '/report',
      component: () => import('./views/ReportView.vue'), // ✅ 懒加载
      children: [
        {
          path: 'chart',
          component: () => import('./components/HeavyChart.vue') // ✅ 组件级再拆
        }
      ]
    }
  ]
})

WebView 环境下卡顿特别明显？绕过浏览器渲染流水线瓶颈

Android 4.4–6.x 的系统 WebView、iOS 12 以下 UIWebView，不支持 requestIdleCallback，且 JS 主线程与渲染线程强耦合。此时任何超过 16ms 的 JS 任务都会导致丢帧。

实操建议：

• 将长任务拆成微任务：用 Promise.resolve().then(() => { /* step 1 */ }) 分片执行数据处理，避免阻塞渲染
• 用 IntersectionObserver 替代 scroll 事件监听滚动位置，减少每帧回调次数
• 强制启用硬件加速但慎用：transform: translateZ(0) 在旧版 Android 上可能引发纹理内存溢出，优先用 transform: translate3d(0,0,0) 并配合 will-change: transform

实际优化效果取决于具体瓶颈点——有时候删掉一行 console.table(data) 就能让切换从 800ms 降到 120ms。别迷信“全面优化”，先用 Performance 面板录一次真实切换过程，看火焰图里最宽的那根条纹是什么函数。