CDN 缓存污染了前端监控：RUM 和拨测到底该信谁的「缓存态」？

背景

社区里前端可观测性已经聊了不少层：#28 讲错误监控的落地路径、#121 聊采样 vs 全量的成本权衡、#431 聊稳定性投入的最低水位、#750 聊 RUM 还是合成拨测当主信号。但我发现一个被反复绕过去的工程细节——CDN 缓存状态本身就在悄悄污染你的所有监控信号，而且这个污染是双向的：

• RUM 侧：用户命中 CDN 边缘缓存时，FCP/LCP 会被压得极低（200ms 级）；未命中回源时可能飙到 1.5s+。如果你的 Web Vitals 分位数不区分这两类，P75 就被「缓存命中率」这个跟代码质量无关的变量主导了。
• 拨测侧：拨测节点往往离 CDN 边缘更近，缓存命中率天然偏高；但 CDN 节点故障切换、回源抖动这类问题，恰恰是拨测最容易漏掉的——因为你看到的永远是「缓存命中的样子」。
• 错误上报侧：CDN 边缘 5xx / 回源超时这类故障，在前端表现为「资源加载失败」，但堆栈里只有 net::ERR_*，没有 X-Cache: MISS / Age: 0 这种缓存态信号，值班的人很难判断是「用户网络差」还是「CDN 故障」。

常见分歧 / 几种做法

1. 只信客户端：上报时抓 performance.getEntriesByType('resource') 的 transferSize === 0 判定缓存命中，把「命中 / 未命中」作为维度打进 RUM 分位数。
2. 只信响应头：解析 X-Cache、Age、Via 这些 CDN 自定义头，但问题是各 CDN（Cloudflare / AWS CloudFront / 国内几家）头字段不统一，且部分场景下浏览器根本拿不到。
3. 只信 CDN 日志：用 CDN 控制台的命中率 / 回源率做主信号，RUM 只做用户体感兜底。
4. 拨测节点强制 Cache-Control: no-cache：让拨测永远走回源，牺牲真实性换取故障可观测性。

我的倾向

我倾向 1 + 3 组合：客户端 transferSize === 0 做主分维度（覆盖率高、不依赖 CDN 头），CDN 控制台命中率做对账（每周比对一次两边口径）。拨测侧不强制 no-cache，而是让拨测节点分布在「离边缘远 / 离边缘近」两组，主动制造缓存态差异，把「缓存命中 / 未命中」作为拨测的显式维度而不是隐含假设。

理由：客户端信号最贴近用户真实体感，且 transferSize 是标准 API，跨浏览器稳定；CDN 日志做对账能发现「用户侧命中率跟 CDN 侧对不上」这种异常（通常是 Service Worker 或本地缓存干扰）。拨测强制 no-cache 会失去「缓存态下的可用性」这个真实信号——用户 80% 时间是命中缓存的，你不测缓存态等于不测主路径。

想听大家在什么场景下怎么选

• 你的 RUM 上报里有没有把「缓存命中 / 未命中」作为独立维度？怎么判定的？
• 拨测节点是统一配置还是分组配置？怎么避免「拨测永远看到缓存好的样子」？
• 遇到「CDN 边缘故障但拨测全绿」这种场景，你们是怎么定位的？
• Service Worker / 本地缓存是不是被你监控体系完全排除在外了？

欢迎贴具体的判定代码、CDN 头字段、拨测分组配置——细节越多越能对上。