1. 概述与准备工作
说明：先明确目标（稳定分配流量并对比页面性能），准备条件：已有网站/静态资源、CDN 服务（如 Cloudflare、Fastly、Akamai、AWS CloudFront）、测试环境（测试域名或子域）、数据采集方案（RUM SDK / 埋点）和 备用回滚策略。小分段：a) 确认生产/测试流量比例；b) 确认需要对比的页面版本（A 与 B）；c) 确认监测指标（TTFB、FCP、LCP、CLS、错误率、缓存命中率）。
2. 选择分流方式与稳定分配原则
说明：推荐两种稳定分配机制：基于 Cookie 的粘滞分配或基于客户端 ID 的哈希分配。小分段：a) Cookie 粘滞：首次请求由边缘生成版本标识（例如 set-cookie: ab_bucket=A），后续请求走同一版本，适合会话级一致性；b) 哈希分配：根据用户 ID、IP+UA 或匿名 ID 做哈希取模（例如 hash(user_id) % 100 < 50 => A），适合无 Cookie 场景；c) 避免基于 CDN 区域随机分配导致缓存碎片化，应尽量让同一用户稳定命中同一缓存键。
3. 设计缓存键与 HTTP 头策略
说明：A/B 页面常导致缓存分裂，必须在 CDN 上合理设计 cache key。小分段：a) 在缓存键中包含版本标识（如 /index.html?v=A），或通过自定义请求头（X-AB-BUCKET: A）并把该 header 纳入缓存 key；b) 设置 Cache-Control/Edge-Control：静态资源长缓存，HTML 根据测试频率设短 TTL 或使用 stale-while-revalidate；c) 使用 Vary 谨慎：若用 Cookie，避免把全部 Cookie 加入 Vary，会造成缓存碎片。
4. 在 CDN 边缘实现分流（实操示例思路）
说明：不同 CDN 实现方式不同，但思路一致：在边缘判断并注入版本标识。小分段：a) Cloudflare Workers：在请求处做 hash 或读 Cookie，决定 A/B，若无 Cookie 则随机并 set-cookie；b) AWS Lambda@Edge / CloudFront：在 viewer-request 中添加逻辑，修改请求 URL 或 header，纳入缓存键；c) Fastly VCL：在 vcl_recv 中计算分桶并修改 req.http.X-AB-BUCKET 与 cache key。示例步骤：1) 在边缘写入分配逻辑；2) 在响应头返回版本（X-Served-Bucket: A）；3) 把该 header 纳入日志与监控。
5. 部署 A/B 页面版本并保证 URL 可区分
说明：为降低缓存冲突，建议生产上部署可区分的静态资源路径或模板编译出带版本前缀的文件。小分段：a) HTML 可采用同域不同路径（/vA/index.html 与 /vB/index.html）或相同 URL 但通过边缘 header 决定内容；b) 对于静态资源（JS/CSS），确保 build 时生成唯一 hash，或在边缘做静态资源重写；c) 确保回滚流程（快速把全部请求切回 A 版本）可执行。
6. 缓存预热与避免冷启动偏差
说明：A/B 测试初期缓存未命中会影响性能比对，必须预热。小分段：a) 在边缘部署完成后，用脚本模拟流量预热每个版本的关键页面与资源；b) 预热策略按流量比例（若 A 70% B 30%，先预热合适比例）；c) 监控边缘缓存命中率，确认达到预期后再开始正式数据采集。
7. 数据采集：RUM 与合成测试并行
说明：结合真实用户监测（RUM）和合成测试能更全面对比性能。小分段：a) RUM：在页面中埋点（或使用浏览器性能 API）上报 TTFB、FCP、LCP、CLS、请求时间、缓存命中标记（来自边缘返回的头）；b) 合成：使用 Lighthouse、WebPageTest 或 Puppeteer 定时请求 A/B 版本（同地理位置、同网络条件多次），记录分布；c) 确保每条上报带上版本标识与用户分桶 ID。
8. 日志与指标收集配置
说明：把边缘日志、CDN 访问日志、RUM 数据统一汇入分析平台（如 ELK、Datadog、BigQuery）。小分段：a) 在 CDN 上开启边缘日志并包含自定义头（X-AB-BUCKET、X-Cache）；b) 保证日志字段含地理、ASN、状态码、latency；c) 建立仪表盘：按版本拆分的 P50/P75/P95 响应时间、缓存命中率、错误率、页面核心体验指标。
9. 统计分析与判定显著性
说明：对比时需做样本量估算与显著性检验。小分段：a) 指标选择：LCP / 成功率 / 页面加载时间，若为转化类指标做二项检验；b) 预估样本量：根据基线率与最小可检测效果（MDE）计算所需访问量；c) 采用 t 检验或贝叶斯方法，控制多次对比的 false discovery（使用置信区间与校正）。
10. 常见问题与防护措施
说明：列出常见风险与应对。小分段：a) 缓存碎片化：避免过多变体键，合并静态资源；b) 跨会话漂移：确保存储分桶信息（Cookie/LocalStorage）与边缘保持一致；c) 地域/网络偏差：按地域分层分析，必要时做分层随机化。
11. 监控与回滚策略
说明：实时监控，一旦异常快速回滚。小分段：a) 建立实时告警（错误率、加载时间超过阈值自动告警）；b) 回滚实现：在 CDN 边缘直接把全部请求路由到 A，或在 CDN 控制台禁用 B 版本；c) 回滚后再次分析缓存、请求日志，定位原因。
12. 实战小结与优化建议
说明：总结要点并给出优化建议。小分段：a) 优先保证“稳定分配+缓存友好”的分配方式；b) 测量要多维（RUM + 合成 + 边缘日志）；c) 持续迭代分流逻辑（例如通过边缘 A/B 测试自身优化路由）。
13. 问：如何确保使用 CDN 做 A/B 测试时不会产生缓存污染？
问：如何确保使用 CDN 做 A/B 测试时不会产生缓存污染？ 答：通过在缓存键中显式包含 A/B 标识（如请求 URL 或自定义 header），并避免将整套 Cookie 或随机值加入 Vary；另外在边缘设置短 TTL 并用预热脚本启动测试版本，能减少污染风险。
14. 问：如果用户从 A 切换到 B，会不会出现体验不一致？如何处理？
问：如果用户从 A 切换到 B，会不会出现体验不一致？ 答：会有风险，解决办法是使用粘滞分配（set-cookie）或在用户首次访问时写入 localStorage/数据库标记，确保同一用户在测试周期内稳定分配；若必须切换，设计平滑降级与数据迁移逻辑。
15. 问：哪些关键指标必须在 A/B 性能对比中关注？
问：哪些关键指标必须在 A/B 性能对比中关注？ 答：至少关注 TTFB、FCP、LCP、CLS、总加载时间、缓存命中率与错误率；同时监测转化/业务指标，按地域和设备分层对比以发现潜在偏差。
