HTML本身不支持合成监控，因其仅为静态结构层，无法主动发起请求或测量时延；必须依赖JavaScript调用fetch、performance API等实现探测、计时、指标采集与上报。
HTML 本身不支持合成监控（Synthetic Monitoring）——它没有主动发起网络请求、模拟用户行为、测量端到端时延的能力。所谓“HTML 做合成监控”，本质是用 HTML 页面作为载体，靠内嵌的 JavaScript 脚本调用 navigator.sendBeacon、fetch 或 XMLHttpRequest 主动探测后端服务，并把结果上报给监控系统。
为什么不能只靠 HTML 标签做合成监控
HTML 是声明式静态结构：<img src="/healthz"> 或 <script src="/probe.js"></script> 确实能触发请求，但它们无法捕获响应时间、HTTP 状态码、TLS 握手耗时、DNS 查询延迟等关键指标；也无法控制超时、重试、错误分类或跨域策略。这些必须由 JS 主动管理。
用 fetch + performance API 实现最小可行合成探测
真实项目中，一个轻量但有效的合成探测脚本需同时采集网络层和应用层指标。核心是利用 performance.getEntriesByType('navigation') 和手动计时结合：
- 在探测前调用
performance.mark('probe-start') - 用
fetch('/api/health', { method: 'HEAD', cache: 'no-store' })避免响应体干扰，专注测连通性与时延 - 用
performance.measure('probe-total', 'probe-start', 'probe-end')获取完整耗时 - 从
performance.getEntriesByName('/api/health')[0]中提取connectStart、responseStart等字段，拆解 DNS / TCP / TLS / TTFB 各阶段 - 失败时捕获
TypeError（如网络中断）和 HTTP 非 2xx 状态码，分开归类
如何避免探测请求污染真实业务埋点
合成监控流量必须与用户真实行为隔离，否则会扭曲 PV、UV、首屏等核心指标：
立即学习“前端免费学习笔记（深入）”；
- 所有探测请求 URL 加统一前缀，如
/synth/probe，便于 Nginx 或 CDN 层直接过滤掉日志记录 - 请求头显式标记：
headers: { 'X-Synth-Probe': 'true' }，后端中间件据此跳过鉴权、审计、限流逻辑 - 禁用 credentials：
credentials: 'omit'，防止携带 Cookie 影响会话状态或触发 CSRF 校验 - 不要复用业务 SDK 的上报通道（如 Sentry、自研日志 SDK），应走独立 endpoint，例如
POST /api/synth/report
定时执行合成探测的三个硬约束
浏览器环境里，setInterval 不可靠——页面后台运行、设备休眠、JS 执行被节流都会导致探测断档。必须用更稳的方式：
- 用
setTimeout链式调用：每次探测完成后再设下一次，确保上一轮结束才启动，避免堆积 - 监听
document.visibilityState：仅当document.visibilityState === 'visible'时才允许探测，后台标签页自动暂停 - 加兜底心跳：若连续 3 次探测失败（超时或网络异常），改用
navigator.sendBeacon强制发一次失败快照到服务端，避免静默失联
真正难的不是发请求，而是让每一次探测都可比、可归因、可定位——比如同一台机器上，Chrome 和 Edge 对同一接口的 TLS 握手时间差 80ms，这个差异是否来自 UA 特性？还是本地代理干扰？得靠固定 User-Agent、关闭预连接、禁用 HTTP/2 推送等细节控制才能说清。
