1. 异步加载到底在解决什么问题1.1 从一次页面卡顿说起我第一次真正意识到异步加载的价值是在一个后台管理系统上。那个页面要同时渲染十几个数据表格每个表格的数据都来自不同的接口。最初的写法很直接页面加载时一个接口一个接口地请求全部拿到数据后再统一渲染。结果就是用户打开页面后要盯着白屏等三四秒期间页面完全没反应点哪里都没用。这个问题本质上不是“接口慢”而是主线程被同步逻辑占满了。浏览器的主线程既要处理网络请求的回调又要执行渲染还要响应用户的点击、滚动。当所有任务都排着队同步执行时用户的操作就只能排在最后面表现出来就是卡顿、无响应。异步加载要解决的核心问题就是这个把不紧急、不阻塞的任务从主线程的关键路径上挪走让页面先能用起来再慢慢把剩下的内容补上。它不是一个具体的技术而是一类思路的统称包括延迟加载、按需加载、并行加载、分片加载等等。1.2 异步加载和性能优化的关系很多人把异步加载和性能优化当成两件事其实前者是后者最核心的手段之一。性能优化关注的指标无非几类首屏时间、可交互时间、帧率、内存占用。异步加载几乎能同时改善这几个指标。举个直观的例子。一个页面有 20 张图片如果全部同步加载浏览器要发起 20 个请求占用大量带宽和连接数首屏图片可能被后面的图片挤到很晚才显示。改成异步加载后首屏只加载可视区域内的 3 张图剩下的等用户滚动到附近再加载。首屏时间立刻从几秒降到几百毫秒带宽也省下来了。提示异步加载不是“越晚加载越好”而是“在正确的时间加载正确的东西”。加载太晚用户滚动时看到空白体验反而更差。这个度需要根据实际场景调。1.3 适合谁来读这篇内容这篇内容适合几类人一是前端开发者尤其是做过中后台系统、电商页面、内容列表的人二是移动端开发者Android 和 iOS 上启动优化、列表滚动优化都绕不开异步加载三是做数据可视化的人图表库渲染大量数据点时异步和分片几乎是必选项。如果你只是写个静态页面可能用不上太复杂的异步策略。但只要你的页面有网络请求、有大量 DOM、有图片或图表异步加载就值得认真对待。下面我会从设计思路、核心细节、实操过程到问题排查把这件事讲透。2. 异步加载的整体设计思路拆解2.1 先分清哪些任务可以异步做异步加载的第一步不是写代码而是给任务分类。我习惯把所有任务按两个维度划分紧急程度和依赖关系。紧急程度指的是这个任务不完成用户能不能正常使用页面。比如首屏的骨架结构、关键文字内容这些是紧急的页面底部的推荐列表、评论区这些是不紧急的。依赖关系指的是这个任务是否依赖其他任务的结果。比如渲染表格依赖接口数据接口数据又依赖用户身份信息这就是一条依赖链。分类之后策略就清晰了紧急且无依赖的任务优先同步执行紧急但有依赖的任务把依赖项并行加载不紧急的任务全部异步化等主流程走完再处理。任务类型紧急程度依赖关系处理策略首屏骨架渲染高无同步执行关键接口数据高依赖用户信息并行请求回调渲染首屏图片高无优先加载可预加载底部推荐列表低依赖接口延迟加载非可视区图片低无懒加载埋点上报低无空闲时执行这张表看起来简单但实际项目中很多人就是没做这一步导致该异步的同步了该同步的反而异步了页面体验一塌糊涂。2.2 并行、串行与分片的选择逻辑确定了哪些任务可以异步之后接下来要决定它们怎么执行。常见的有三种模式并行、串行、分片。并行就是多个任务同时发起谁先完成谁先处理。适合彼此独立、没有依赖关系的任务。比如首屏要请求用户信息、配置信息、消息数量三个接口它们互不依赖并行请求能把总耗时从三个接口之和降到最慢那个接口的耗时。串行就是一个接一个执行前一个完成才开始下一个。适合有严格依赖关系的任务。比如要先拿到 token 才能请求业务数据那就必须串行。但串行不等于同步阻塞可以用 Promise 链或者 async/await 写成非阻塞的形式。分片是把一个大任务拆成多个小任务分批执行。适合计算量大或者数据量大的场景。比如要渲染一万条数据一次性渲染会卡死主线程拆成每批 100 条用 requestAnimationFrame 或者 setTimeout 分批渲染页面就不会卡。选择哪种模式核心看两点任务之间有没有依赖单个任务会不会阻塞主线程太久。没有依赖就并行有依赖就串行但非阻塞任务太大就分片。2.3 加载时机的判断什么时候触发异步异步加载的触发时机决定了用户体验。常见的触发方式有几种立即异步、延迟异步、可视区触发、交互触发、空闲触发。立即异步就是页面初始化时就把异步任务挂上去但不阻塞主流程。适合那些虽然不紧急但迟早要用的资源比如页面底部的图片。延迟异步是等一段时间后再加载比如 setTimeout 延迟 200 毫秒。这个“延迟”不是随便定的而是给主流程让路让首屏渲染先完成。延迟太久用户会感知到空白太短又起不到让路的作用一般 100 到 300 毫秒比较合适。可视区触发就是常说的懒加载用 IntersectionObserver 监听元素是否进入视口。这个方案现在兼容性已经很好了比早年用 scroll 事件加 getBoundingClientRect 的方案性能好很多因为不需要频繁计算位置。交互触发是等用户操作后再加载比如点击“查看更多”才加载下一页。适合那些用户不一定需要的功能避免浪费带宽。空闲触发是用 requestIdleCallback 在浏览器空闲时执行。适合埋点上报、预加载下一页资源这类完全不紧急的任务。不过 requestIdleCallback 在部分环境支持不完整实际项目中通常用 setTimeout 做降级。2.4 为什么不用同步加载硬扛有人会想既然异步这么麻烦那我优化接口速度、压缩资源同步加载不也行吗这个思路在简单页面可行但在复杂页面会撞墙。同步加载的问题在于它把“加载”和“渲染”绑死了。只要有一个资源没到位后面的渲染就得等。而网络是不稳定的接口响应时间波动很大你没法保证每个资源都很快。一旦某个接口慢了整个页面就卡住。异步加载的本质是解耦加载归加载渲染归渲染两者通过回调或状态管理连接。这样即使某个资源慢了页面其他部分照样能用。用户感知到的不是“页面卡住了”而是“这部分内容还在加载中”体验完全不同。3. 核心细节解析与实操要点3.1 图片懒加载的实现细节图片懒加载是异步加载里最经典也最实用的场景。核心思路是图片的真实地址不放在 src 上而是放在>const observer new IntersectionObserver((entries) { entries.forEach(entry { if (entry.isIntersecting) { const img entry.target; img.src img.dataset.src; observer.unobserve(img); } }); }, { rootMargin: 200px 0px, threshold: 0 }); document.querySelectorAll(img[data-src]).forEach(img { observer.observe(img); });这里有几个细节值得说。rootMargin 设置为 200px意思是图片距离视口还有 200px 时就开始加载这样用户滚动到图片位置时图片大概率已经加载好了不会看到空白。threshold 设为 0 表示只要有一点进入视口就触发。加载完成后要调用 unobserve否则图片会一直被观察浪费性能。这个细节很多人会漏掉。注意图片懒加载要处理好占位。如果图片没有设置宽高加载前高度为 0加载后突然撑开会导致页面抖动。解决办法是给图片设置固定的宽高比或者用 padding-top 撑开容器。3.2 接口请求的并发控制页面初始化时经常要请求多个接口如果无脑并行可能瞬间发出几十个请求浏览器对同域名的并发连接数有限制超出的请求会排队反而拖慢关键请求。我一般会做一个并发控制器限制同时进行的请求数量。比如限制为 6 个超出的排队等待。这样既能利用并发又不会把连接数占满。class RequestPool { constructor(limit 6) { this.limit limit; this.running 0; this.queue []; } add(task) { return new Promise((resolve, reject) { this.queue.push({ task, resolve, reject }); this.run(); }); } run() { while (this.running this.limit this.queue.length) { const { task, resolve, reject } this.queue.shift(); this.running; task() .then(resolve) .catch(reject) .finally(() { this.running--; this.run(); }); } } }这个控制器的关键点是running 计数和 queue 队列配合保证同时运行的请求不超过 limit。每个请求结束后从队列取下一个形成流水线。实际使用时把关键接口放在队列前面非关键接口放后面这样即使排队关键接口也能优先执行。3.3 大数据量渲染的分片策略渲染一万条数据到页面上如果一次性 append主线程会被占满页面直接卡死几秒。解决办法是分片渲染每批渲染一部分批次之间让出主线程。function renderInChunks(data, chunkSize 100) { let index 0; const container document.getElementById(list); function renderChunk() { const fragment document.createDocumentFragment(); const end Math.min(index chunkSize, data.length); for (let i index; i end; i) { const item document.createElement(div); item.textContent data[i].name; fragment.appendChild(item); } container.appendChild(fragment); index end; if (index data.length) { requestAnimationFrame(renderChunk); } } renderChunk(); }这里用 DocumentFragment 是关键。如果每创建一个元素就 append 到容器会触发多次重排。用 Fragment 先在内存里组装最后一次性 append只触发一次重排。chunkSize 的选择要看单个元素的复杂度。简单文本元素可以设 100 到 200复杂元素比如带图片和交互的卡片设 20 到 50 比较稳妥。判断标准是单批渲染时间控制在 16 毫秒以内这样不会掉帧。3.4 异步任务的错误处理异步加载最容易出问题的地方是错误处理。同步代码出错会直接抛异常容易发现。异步代码出错如果没捕获可能悄无声息地失败用户看到的就是一直加载中。每个异步任务都要有失败处理。接口请求失败要有重试机制图片加载失败要有兜底图分片渲染失败要能回滚或者提示。async function loadWithRetry(fn, retries 3, delay 1000) { for (let i 0; i retries; i) { try { return await fn(); } catch (err) { if (i retries - 1) throw err; await new Promise(r setTimeout(r, delay * (i 1))); } } }重试的间隔我用了递增策略第一次等 1 秒第二次等 2 秒第三次等 3 秒。这是因为如果接口是因为压力大而失败立即重试只会加重压力递增等待能给服务端喘息时间。提示重试不是万能的。如果是 404 或者参数错误重试多少次都没用。重试只针对网络超时、5xx 这类临时性错误。4. 完整实操过程与核心环节实现4.1 搭建一个可复用的异步加载模块光有零散的技巧不够实际项目里需要一个统一的异步加载模块。我设计过一个简单的模块包含任务注册、并发控制、超时处理、重试、状态回调几个部分。先定义任务的结构const task { id: user-info, priority: 1, timeout: 5000, retries: 2, executor: () fetch(/api/user).then(r r.json()), onSuccess: (data) { /* 渲染用户信息 */ }, onError: (err) { /* 显示错误提示 */ } };priority 数字越小优先级越高调度时优先执行。timeout 是超时时间超过就中断。executor 是实际执行函数返回 Promise。调度器的核心逻辑是按优先级排序并发执行每个任务独立处理超时和重试。class AsyncLoader { constructor(concurrency 6) { this.concurrency concurrency; this.tasks []; this.running 0; } register(task) { this.tasks.push(task); this.tasks.sort((a, b) a.priority - b.priority); } start() { while (this.running this.concurrency this.tasks.length) { const task this.tasks.shift(); this.execute(task); } } async execute(task) { this.running; try { const result await this.withTimeout( this.withRetry(task.executor, task.retries), task.timeout ); task.onSuccess task.onSuccess(result); } catch (err) { task.onError task.onError(err); } finally { this.running--; this.start(); } } withTimeout(promise, ms) { return Promise.race([ promise, new Promise((_, reject) setTimeout(() reject(new Error(timeout)), ms) ) ]); } async withRetry(fn, retries) { for (let i 0; i retries; i) { try { return await fn(); } catch (err) { if (i retries) throw err; await new Promise(r setTimeout(r, 1000 * (i 1))); } } } }这个模块用起来很直接注册任务调用 start剩下的交给调度器。每个任务的成功和失败都有回调业务代码只需要关心回调里怎么渲染。4.2 首屏加载的完整时序安排首屏加载是异步加载最重要的场景时序安排得好首屏时间能缩短一半以上。我一般按这个顺序安排第一步HTML 解析到关键 CSS 和骨架屏立即渲染骨架。骨架屏不需要等任何接口纯静态让用户马上看到页面结构。第二步并行发起关键接口请求。关键接口指的是首屏必须展示的数据比如用户信息、首屏列表数据。这些接口用高优先级注册到调度器。第三步首屏图片开始加载。图片可以用 preload 提前声明让浏览器尽早开始下载。第四步骨架屏渲染完成后接口数据陆续返回用数据替换骨架。这一步要注意替换时不要引起布局大幅跳动骨架的尺寸要和真实内容接近。第五步首屏完成后启动非关键任务。底部推荐、非可视区图片、埋点上报这些全部异步执行。这个时序的关键是骨架屏先行。很多项目首屏白屏时间长就是因为非要等接口数据回来才渲染。骨架屏让用户立刻有反馈感知上的等待时间大大缩短。4.3 移动端启动性能的异步优化移动端和 Web 端有个很大的不同移动端的资源加载和渲染更受限于设备性能。同样的异步策略在高端机上没问题在低端机上可能还是卡。Android 启动优化里有个重要原则启动阶段只做必须做的事。很多应用启动慢是因为在 Application 的 onCreate 里初始化了一堆 SDK每个 SDK 都要读配置、开线程、注册监听。这些初始化如果同步做启动时间直接爆炸。我的做法是把初始化分成三批第一批是启动必须的比如崩溃监控、核心配置同步初始化第二批是首页需要的比如网络库、图片库异步初始化首页渲染前完成即可第三批是其他页面才用的比如分享、支付等首页展示后再初始化。// 第一批同步 CrashMonitor.init(context); CoreConfig.init(context); // 第二批异步首页渲染前完成 AsyncInit.post(() - { NetworkLib.init(context); ImageLoader.init(context); }); // 第三批首页展示后 mainHandler.postDelayed(() - { ShareSdk.init(context); PaySdk.init(context); }, 3000);这个分批策略的核心是按需初始化。不用的东西不初始化用的东西按时间要求初始化。实测下来启动时间能优化 30% 到 50%。4.4 数据可视化的异步渲染图表类场景对异步加载的要求更高。一个折线图如果有几千个数据点一次性渲染会卡如果用 Canvas 还好用 SVG 的话 DOM 节点数量直接爆炸。我的做法是分两步先渲染一个简化版的图表比如只取每 10 个点里的 1 个快速画出大致趋势然后再异步渲染完整数据用 requestIdleCallback 在空闲时分批绘制。function renderChart(data) { // 第一步采样渲染快速出图 const sampled data.filter((_, i) i % 10 0); drawChart(sampled); // 第二步空闲时渲染完整数据 if (window.requestIdleCallback) { requestIdleCallback(() { drawChart(data); }); } else { setTimeout(() drawChart(data), 200); } }采样渲染让用户立刻看到图表完整渲染在后台悄悄完成。用户感知不到两次渲染的切换因为采样后的趋势和完整数据基本一致。注意采样渲染适合趋势展示不适合精确读数。如果用户需要看具体数值采样版本要标注“数据加载中”避免误导。5. 常见问题与排查技巧实录5.1 异步加载导致的内存泄漏异步加载最常见的坑是内存泄漏。页面已经销毁了异步任务还在跑回调里还在操作已经移除的 DOM轻则报错重则内存持续增长。我排查过一个典型问题列表页滚动加载用户快速滚动后退出页面结果控制台报了一堆“Cannot read property of null”。原因是图片懒加载的 IntersectionObserver 没有断开页面销毁后还在观察已经不存在的元素。解决办法是在页面销毁时清理所有异步任务和观察器// 页面初始化时 const observer new IntersectionObserver(handleIntersect); const abortController new AbortController(); // 页面销毁时 function destroy() { observer.disconnect(); abortController.abort(); // 清理定时器 clearTimeout(timer); clearInterval(interval); }AbortController 是取消 fetch 请求的标准方式比手动维护标志位干净得多。所有异步任务都应该有对应的取消机制这是硬性要求。5.2 异步顺序错乱的问题多个异步任务并行执行时完成顺序是不确定的。如果业务逻辑依赖顺序就会出问题。我遇到过一个场景先请求用户信息再根据用户 ID 请求订单列表。两个请求并行发出结果订单列表先返回此时用户信息还没到订单列表渲染时拿不到用户 ID直接报错。解决办法是显式声明依赖。有依赖关系的任务不能并行要用 Promise 链或者 async/await 串起来async function loadData() { const user await fetchUser(); const orders await fetchOrders(user.id); render(user, orders); }如果确实想并行但又要保证处理顺序可以用 Promise.all 收集结果后统一处理const [user, config] await Promise.all([fetchUser(), fetchConfig()]); // 这里 user 和 config 都到位了顺序有保证5.3 常见问题速查表问题现象可能原因排查方向解决办法页面白屏时间长关键资源同步加载看 Network 瀑布图骨架屏先行关键接口并行滚动卡顿懒加载计算频繁Performance 面板看帧率改用 IntersectionObserver内存持续增长异步任务未清理Memory 面板看堆快照页面销毁时取消任务数据渲染错乱异步顺序不确定看请求返回顺序显式声明依赖串行处理图片加载失败无提示缺少错误处理看控制台报错加 onerror 兜底图首屏图片被挤后并发数占满看请求排队情况关键图片 preload 提权分片渲染仍卡顿单批数据量过大测单批渲染耗时减小 chunkSize重试加重服务压力无退避策略看重试时间间隔递增等待限制重试次数5.4 几个容易被忽略的实操心得第一个心得异步加载的优先级要动态调整。用户滚动到页面底部时底部内容的优先级就变高了应该从队列后面提到前面。我一般会维护一个优先级队列根据用户行为动态调整。第二个心得预加载要克制。预加载能提升体验但会消耗带宽。移动端用户可能用的是流量无节制的预加载是在偷用户的钱。我的原则是只预加载用户大概率会访问的下一页而且要在 Wi-Fi 环境下才预加载大资源。第三个心得异步任务的超时时间要分级。关键接口超时可以短一点比如 3 秒快速失败让用户重试非关键接口超时可以长一点比如 10 秒反正不影响主流程。统一设一个超时时间是不合理的。第四个心得监控异步任务的失败率。异步任务失败往往悄无声息用户不反馈你就不知道。我一般会在 onError 里上报埋点统计每个接口的失败率和失败原因定期看报表优化。第五个心得不要过度异步。有些任务本身很快同步执行反而简单可靠。异步是有成本的代码复杂度增加、调试难度增加、错误处理增加。只有确实会阻塞主流程的任务才值得异步化。6. 异步加载的边界与取舍6.1 什么时候不该用异步异步加载不是银弹。有些场景用异步反而添乱。比如一个简单的表单页面只有几个输入框和一个提交按钮没有任何网络请求和大量 DOM。这种页面同步加载完全没问题硬套异步框架只会让代码变复杂。再比如强依赖顺序的业务流程每一步都必须等上一步完成。这种场景用 async/await 写成串行逻辑最清晰强行并行反而容易出 bug。判断标准很简单如果同步执行不会让用户感知到等待就不需要异步。异步是为了解决等待问题没有等待问题就不需要它。6.2 异步带来的复杂度如何控制异步的代价是复杂度。回调地狱、状态管理、错误处理、竞态条件每一个都是坑。控制复杂度有几个原则。第一用 async/await 代替回调。async/await 让异步代码看起来像同步代码可读性大幅提升。能用 async/await 就不用 then 链更不用回调。第二统一错误处理。不要在每个异步任务里写 try/catch而是在外层统一捕获。比如在调度器里统一处理错误业务代码只关心成功回调。第三限制异步层级。异步套异步套异步代码就没法维护了。我一般要求异步层级不超过两层超过就抽成独立函数。第四状态可视化。异步任务的状态加载中、成功、失败要能直观看到。我习惯给每个异步区域加一个状态标记调试时一眼就能看出哪个任务卡住了。6.3 性能优化的整体视角异步加载只是性能优化的一环。真正做好性能需要从整体视角看问题。网络层面要减少请求数、压缩资源、用缓存。异步加载解决的是请求时机问题但请求本身的大小和数量也要优化。渲染层面要减少重排重绘、用虚拟列表、避免布局抖动。异步加载解决的是加载时机问题但渲染本身的效率也要优化。计算层面要避免长任务、用 Web Worker 处理复杂计算。异步加载解决的是主线程阻塞问题但计算量本身也要控制。这几个层面是配合的。异步加载把任务挪到合适的时机但如果任务本身很重挪到什么时候都会卡。所以异步加载要和资源压缩、代码分割、虚拟列表这些手段一起用才能达到最佳效果。我在实际项目中的体会是性能优化没有一招制敌的办法都是一个个小优化累积起来的。异步加载是其中性价比很高的一个投入不大收益明显。但也不要指望它解决所有问题该做的资源优化、代码优化一个都不能少。最后分享一个小技巧做异步加载优化时一定要用真实设备测。模拟器的性能往往比真机好在模拟器上流畅的方案到低端真机上可能就卡了。我一般会找一台两三年前的中低端手机做基准测试能在这台机器上跑顺基本就没问题了。