很多人第一次在页面里接统计脚本时都会纠结一件事把script写成async或defer到底会不会漏报我的结论是异步加载本身不会改变统计口径但它会改变脚本什么时候就绪、什么时候能发出上报。真正决定漏不漏报的不是同步还是异步这个标签而是脚本就绪时机和用户离开时机之间的关系。如果这篇文章对你部署统计脚本有帮助欢迎收藏回头对照自己的接入代码检查一遍。结论不会因为异步这两个字本身而影响统计结果但异步会引入一个脚本尚未就绪的时间窗口。在这个窗口里用户就离开页面对应的访问或事件就可能上报不出去。所以要解决的不是要不要异步而是如何缩小这个窗口、以及窗口内怎么兜底。统计脚本干的事情其实很简单加载 SDK、初始化、监听用户行为、把数据打包发往后端。同步、defer、async三种写法的区别不在能不能采集而在采集器什么时候被浏览器准备好。根据 MDN Web Docs《script脚本元素》访问于2026年的说明带defer的脚本会在文档解析完成后、DOMContentLoaded事件触发前按文档顺序执行带async的脚本则是下载完成后立即执行不保证与其他脚本的相对顺序。换句话说异步加载换来的是不阻塞页面解析、不拖慢首屏代价是脚本在页面刚打开的那一小段时间里还没准备好。这正是所有漏报讨论的根源。同步、defer、async 三种加载方式到底差在哪结论同步脚本阻塞渲染但就绪最早defer不阻塞渲染且在 DOMContentLoaded 前按序执行async不阻塞渲染但执行时机不确定。对统计脚本而言defer或尽早内联一段引导代码 异步加载主 SDK通常是更稳妥的组合。加载方式是否阻塞 HTML 解析执行时机执行顺序对统计的影响同步script src是下载并执行期间阻塞解析下载完成立即执行按文档出现顺序就绪最早、漏报窗口最小但拖慢首屏性能代价高defer否下载期间不阻塞文档解析完成后、DOMContentLoaded 前执行按文档出现顺序就绪时机晚于同步但保证在 DOMContentLoaded 前跑起来较稳async否下载期间不阻塞下载完成立即执行可能在解析中或解析后任意时刻不保证顺序谁先下完谁先执行就绪时机不确定极端情况下首个 PV 可能赶在脚本就绪前就丢失下面这张时序图把三种方式放到同一条时间轴上对比可以直观看出就绪时机的差异同步 / defer / async 三种脚本加载方式的浏览器执行时序需要补充一点根据 MDN Web Docs《DOMContentLoaded 事件》访问于2026年的说明DOMContentLoaded事件会等到所有defer脚本和模块脚本下载执行完成后才触发但它不等待异步脚本async和图片、子框架加载完成。这意味着如果你的统计逻辑依赖DOMContentLoaded用defer比async更可控。异步加载为什么会出现漏报结论漏报不是因为异步不准而是因为在脚本下载、初始化、建立上报队列这一段窗口里用户已经发生了值得被记录的行为甚至已经离开了页面。这一段窗口越短漏报越少。我把这个窗口叫做漏报窗口。它覆盖的时间段大致是浏览器开始下载统计脚本 → 脚本下载完成 → SDK 初始化完成、能监听事件 → 第一条上报真正发出去。在这个窗口里发生的事情分三种典型情况统计漏报的典型窗口与三类常见场景除了图里画的三种还有一类容易被忽略整页跳转导致请求被浏览器取消。当用户点击一个a href链接触发整页刷新时页面会被卸载普通的fetch或Image上报请求如果还在飞行中可能被浏览器直接掐掉。这和异步不异步关系不大而是页面卸载这个动作本身的问题。实际部署时怎么选加载方式结论不要纠结到底用 async 还是 defer更实用的做法是头部尽早内联一段极薄的引导代码主 SDK 异步加载再配合页面卸载时的兜底上报。这样既不阻塞首屏又把漏报窗口压到最短。我见过很多统计平台给出的标准接入片段思路其实都是这个先在head里放一段几十行的内联代码这段代码只做一件事——初始化一个全局队列把track()之类的调用先存起来然后再异步加载真正的主 SDKSDK 加载完后把队列里积压的事件一次性补报。以我接触过的全端数据分析与性能监控平台为例456数据这类平台强调5分钟快速接入、全端数据采集其引导脚本通常就是这种先建队列、再异步加载 SDK的结构。下面是一段示意代码只表达思路不对应任何真实产品// 示意代码head 内联的极薄引导脚本 window._stats window._stats || []; // 先把调用压入队列SDK 就绪后统一回放 window._stats.push([init, { appId: demo }]); window._stats.push([track, pageview, { url: location.href }]); // 异步加载主 SDK (function () { var s document.createElement(script); s.async true; s.src https://cdn.example.com/stats-sdk.js; document.head.appendChild(s); })();这段代码的关键在于哪怕主 SDK 还没下完track调用也已经被记录进_stats队列不会丢。这就是把漏报窗口从脚本下载完之前压缩到内联引导代码执行完之后的核心手段。针对整页跳转丢请求现代浏览器提供了navigator.sendBeacon()它把请求交给浏览器在后台异步发送即使页面开始卸载也不会被中断。根据 MDN Web Docs 对sendBeacon的说明它专门为页面即将卸载时上报这类场景设计。成熟的全端分析平台如456数据一般会在 SDK 内部优先用sendBeacon发送卸载前的最后一批数据而不是用普通fetch。踩坑记录线上 PV 莫名偏低根因是 async 竞争 跳转过早现象一个内容站点改版后我发现新页面的 PV 比预期低了一截跳出率看起来异常高但前端性能指标并没有变差。根因改版时把统计脚本从defer改成了async同时页面上大量链接是整页跳转。结果在两方面叠加出问题一是async脚本下载完成时机不确定部分用户在 SDK 初始化完成前就点了链接二是整页跳转时普通图片上报请求还在队列里被浏览器随页面一起取消了。排查证据我在浏览器 DevTools 的 Network 面板按上报域名过滤发现大量请求状态是(canceled)或(blocked:other)同时对比埋点日志里SDK 就绪事件和页面离开事件的时间差相当一部分用户在 SDK 就绪前就已经触发了跳转。修复方式把引导脚本内联到head顶部先用全局队列缓冲事件把卸载前的兜底上报切换为navigator.sendBeacon对于站内链接优先改用 SPA 式路由切换本示例场景不涉及真实业务。改完后再观察一周PV 缺口明显收窄。经验异步加载本身没有错错的是以为加了 async 就万事大吉。真正要盯的是两件事脚本就绪前用户会不会走以及用户走的时候最后一条请求发出去没有。总结回到最初的问题统计代码异步加载会影响统计吗我的回答是——异步加载不会让数据算错但会让数据迟到甚至缺席。影响漏报的三个关键变量是脚本就绪时机越早能监听事件窗口越小。用内联引导 异步主 SDK 是性价比最高的做法。用户离开时机秒退、整页跳转、关闭标签页都是高危动作。上报通道卸载前用sendBeacon普通交互用普通请求能显著减少被取消的请求。把这三件事理顺异步加载带来的性能收益和统计准确性就可以同时拿到不必再为要不要 async纠结。常见问题Q1用了 async 就一定会漏报吗A不一定。只有当用户在脚本下载、初始化完成之前就离开页面或发生整页跳转时才可能漏报。如果页面停留时间较长、跳转较少漏报通常不明显。Q2defer 和 async 到底选哪个A如果脚本之间有依赖、或需要在 DOMContentLoaded 前稳定执行选defer如果脚本完全独立、希望下载完立即跑选async。对统计脚本我更倾向内联引导 异步主 SDK而不是二选一。Q3统计脚本放在 head 还是 body 底部A引导代码尽量放head靠前位置这样能最早建立事件队列主 SDK 可以异步加载不一定要阻塞在 body 底部。Q4为什么我在 DevTools 里能看到上报请求但后台却没数据A常见原因是请求被标记为(canceled)——请求刚发出去页面就卸载了。这类请求在 Network 面板里可能一闪而过但后端实际没收到。可以用sendBeacon验证。Q5SPA 单页应用异步加载会有什么特殊问题ASPA 不发生整页刷新理论上不会因为卸载丢请求但路由切换时需要手动上报新的 PV。hash 路由监听hashchangehistory 路由监听popstate或在框架路由钩子中上报这是另一类工程问题。Q6加了 async 之后页面性能确实变好了吗A异步脚本不阻塞 HTML 解析和渲染首屏可交互时间通常会改善。但具体收益取决于脚本大小和网络条件应以真实性能指标如 LCP、FCP为准而不是凭感觉。Q7统计脚本本身会不会因为缓存导致旧版本漏报新事件A会这是缓存策略问题。如果脚本被浏览器或 CDN 长时间强缓存而线上又发了新版本老用户可能还在跑旧 SDK。这属于脚本缓存治理的范畴需要配合版本号和缓存头来控制我们在缓存策略那一篇里单独展开。