WKWebView跳转白屏卡顿主因是主线程被JS或渲染阻塞，需禁用默认导航拦截、优化代理方法、约束前端跳转行为、启用预热与硬件加速，并复用WebView实例及JSCore上下文。
WKWebView 加载 HTML5 页面跳转时白屏/卡顿的典型表现
不是页面加载慢，而是点击链接或执行 window.location.href、history.pushState 后，界面卡住 300–800ms 才响应——尤其在低端 iPhone 或页面含大量 JS 的场景下明显。这本质是 WKWebView 主线程被 JS 执行或渲染阻塞，而非网络问题。
禁用 WKWebView 默认的导航拦截逻辑（关键一步）
WKWebView 默认对每次导航都触发 webView:decidePolicyForNavigationAction:decisionHandler:，若代理方法里做了同步耗时操作（比如调用 JS 拿 token、查本地缓存），就会直接卡住跳转。必须确保该代理方法内只做轻量判断，且所有异步操作用 dispatch_async(dispatch_get_main_queue(), ^{...}) 延后执行。
- 避免在
decisionHandler中直接调用evaluateJavaScript:completionHandler: - 如需鉴权，改用预加载 JS 注入 token 到
window对象，跳转时由前端自行携带 - 对非必要跳转（如
tel:、mailto:、itms-apps:）应快速返回WKNavigationActionPolicyCancel，别走完整流程
控制 HTML5 页面自身的跳转行为
前端不配合的话，再好的 WebView 配置也白搭。重点约束三类高危操作：
- 禁止在
click回调里同步执行复杂 JS（如遍历大数组、重绘 Canvas），改用requestIdleCallback或拆成微任务 -
location.href = url比history.pushState更易触发重绘卡顿，优先用后者 +replaceState配合popstate监听 - 移除跳转前的
console.log、debugger和未 catch 的 Promise reject（iOS Safari 对未处理异常更敏感）
启用 WKWebView 硬件加速与预热策略
WKWebView 实例创建和首次渲染开销大，冷启动跳转必然卡。不能等用户点才初始化：
立即学习“前端免费学习笔记（深入）”；
- App 启动后立即创建一个隐藏的
WKWebView实例并加载空白页（about:blank），保持其存活 - 在需要跳转前，用
webView.configuration.processPool复用已有进程池，避免重复 fork WebContent 进程 - 设置
webView.allowsBackForwardNavigationGestures = NO，禁用边缘滑动手势——该手势会强制触发渲染管线重排，加剧卡顿
真机上最易被忽略的是 JSCore 上下文复用：如果每次跳转都新建 WebView，JS 引擎要重新解析、编译、JIT，这部分延迟比网络还重。保持单例 WebView + SPA 路由是最稳妥的解法。
