统计代码应优先放在末尾并加async或defer，避免阻塞渲染；依赖dom时才放底部；多脚本共存需统一async、包装api调用；sendbeacon仅适用于卸载前终态上报。
统计代码该放
绝大多数第三方统计脚本（如百度统计、Google Analytics、友盟）推荐放在 末尾，但必须加 async 或 defer。不加会导致页面渲染阻塞，首屏时间明显变长。如果脚本本身依赖 DOM（比如某些老版本友盟），才退而求其次放 底部——但这是兼容性妥协，不是最佳实践。
常见错误现象：DOMContentLoaded 触发延迟、Lighthouse 报 “Render-blocking resources”、用户还没看到内容，浏览器卡在下载统计 JS 上。
- 优先用
<script async src="https://example.com/stat.js"></script>，适用于不依赖 DOM 的现代统计 SDK - 若需确保 DOM 已就绪（例如手动调用
_trackEvent），改用defer，且仍放在内 - 避免在
开头插入统计脚本——它会阻塞后续 HTML 解析，比放更差
多个统计脚本共存时的加载冲突怎么避？
不同统计服务常各自注入全局变量（如 __gaTracker、_hmt、UMID），脚本执行顺序错乱或重复初始化，会导致数据漏报或上报异常。核心原则：不共享执行上下文，不假设加载顺序。
典型场景：A/B 测试平台 + 主站统计 + 埋点 SDK 同时嵌入；某脚本内部调用了 window.ga，但 Google Analytics 尚未加载完成。
- 所有第三方脚本统一用
async，禁止混用async和defer—— 否则执行时机不可控 - 不要在统计脚本外直接调用其 API（如
gtag('event', ...)），应包装成等待函数，检查typeof gtag === 'function'再执行 - 敏感操作（如页面停留时长计算）建议延迟到
load事件后触发，避开脚本加载竞争
navigator.sendBeacon() 能替代传统统计上报吗？
能，但仅适用于“页面卸载前”的最后一条数据（如停留时长、退出页）。它不解决脚本加载、初始化、采样逻辑等问题，只是上报通道升级。如果你的统计服务商没提供基于 sendBeacon 的 SDK 封装，自行实现容易丢数据。
使用场景：用户关闭标签页、跳转到站外链接、刷新页面前，需要强保障的终态上报。
-
sendBeacon只支持POST，且 payload 限制约 64KB，不适合上报大量自定义事件 - 必须配合服务端接收端支持（如识别
Content-Type: text/plain），否则 415 错误静默失败 - 旧版 Safari（XMLHttpRequest +
beforeunload
如何验证统计代码是否生效且无异常？
不能只看控制台有没有报错，重点查三件事：请求是否发出、参数是否正确、服务端是否接收。很多“看似运行成功”的脚本，实际因域名白名单、HTTPS 混合内容、CSP 策略被拦截。
最容易被忽略的是 CSP（Content-Security-Policy）头：如果设置了 script-src 'self'，外部统计域名必须显式加入，否则脚本根本不会执行。
- 在 Network 面板过滤
collect、log、utm.gif等关键词，确认有 200 请求发出 - 检查请求 Query 参数，特别是
url、title、rnd是否为真实值，而非undefined或空字符串 - 临时禁用 CSP 或添加
script-src 'self' https://*.baidu.com https://www.google-analytics.com测试
复杂点在于统计 SDK 往往做多层封装和延迟上报，一次页面访问可能触发 3–5 次请求，其中任意一环被拦截，数据就断档。盯着 Network 看 5 秒，比刷 10 次控制台更有用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
