小白也能懂：用CDN边缘计算做无服务器A/B测试，告别笨重的后端路由

为什么你的A/B测试需要“搬家”到边缘？

我的处理经验

说到CDN Edge，很多问题都出在细节上。传统A/B测试通常有两种实现方式：

• 服务端路由：用户在请求页面时，后端服务器根据用户ID或随机数决定返回哪个版本的HTML。这种方式需要修改后端代码，增加了服务端负担，而且每次实验上线都需要重启或重新部署。
• 客户端JavaScript：通过JS在浏览器端动态切换页面元素或样式。这种方法虽然灵活，但会造成“闪烁”问题（用户先看到原版，再被替换成实验版），而且对SEO不友好，爬虫可能只抓取到默认版本。

两种方式共同的痛点：延迟和侵入性。传统的A/B测试逻辑往往嵌入在业务代码中，任何实验变更都可能影响核心功能的稳定性。而CDN边缘计算提供了一个全新的思路——在离用户最近的地方（CDN节点）完成分流决策，既不需要动后端代码，也不需要依赖浏览器端的JS，这就是Edge Side A/B测试。

先搞懂三个基础概念

1. 什么是CDN边缘计算？

CDN（内容分发网络）原本只负责缓存和加速静态资源。边缘计算则让CDN节点具备了“运算能力”——你可以在全球分布的节点上运行一段轻量级的代码（比如Cloudflare Workers、Akamai EdgeWorkers、Fastly Compute@Edge）。这些代码在用户请求到达源站之前就被执行，可以改写请求、响应，甚至直接生成内容。

2. 什么是无服务器（Serverless）？

无服务器不是真的没有服务器，而是你不需要关心服务器的运维、扩容和部署。你只需要写一段函数（比如一个JavaScript函数），平台会自动在分布式节点上执行它，按实际调用次数计费。对小白来说，理解成“我只写逻辑，平台帮我跑”就够了。

3. 什么是Cookie路由？

Cookie是浏览器存储的一小段文本，服务器可以通过HTTP头设置让浏览器带上它。Cookie路由就是利用Cookie中的值（比如测试分组标识）来让CDN边缘计算决定用户访问哪个版本的页面。例如：一个叫 ab_test_group 的Cookie，值为“A”时返回原始版本，值为“B”时返回实验版本。

Edge Side A/B测试的工作原理

实际操作要点

传统上，A/B测试的分组逻辑通常在源站服务器完成。而Edge Side的做法是：

1. 用户第一次请求某个URL（比如 /）时，CDN边缘节点检查请求中是否携带了 ab_test_group Cookie。
2. 如果没有该Cookie，说明用户是第一次访问，边缘计算代码会按照预设的分组比例（比如50%/50%）随机分配一个分组（A或B），并设置一个Cookie返回给用户（通过 Set-Cookie 响应头）。
3. 如果已经存在该Cookie，则直接读取分组值。
4. 根据分组值，边缘计算代码重写请求路径或修改响应内容：比如将 / 重写为 /index-a.html 或 /index-b.html，然后去源站获取对应的静态页面；或者直接返回缓存中的不同版本。
5. 整个过程用户无感知，所有逻辑运行在CDN节点上，源站只需要正常响应即可。

这种模式的好处是：源站不需要知道任何实验逻辑，甚至源站可以是一个静态文件服务器；CDN边缘计算负责分流，而且因为分流发生在离用户最近的节点，延迟极低。

CDN Edge：一步一步实现：用Cloudflare Workers做A/B测试

以下用Cloudflare Workers为例（其他平台逻辑类似），展示一个最简单的Cookie路由A/B测试。假设你有两个静态页面 www.example.com/page-a 和 www.example.com/page-b，你想各展示给50%的用户。

准备工作

• 一个Cloudflare账号，并开启Workers功能（免费套餐每天10万次请求足够测试）。
• 你的域名已经接入Cloudflare。
• 准备好两个版本的页面（可以是两种不同的样式或文案）。

编写Worker代码

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const cookieHeader = request.headers.get('Cookie') || '';

    // 检查是否存在ab_test_group Cookie
    const match = cookieHeader.match(/ab_test_group=(A|B)/);
    let group;

    if (match) {
      group = match[1];
    } else {
      // 随机分配分组
      group = Math.random() < 0.5 ? 'A' : 'B';
    }

    // 根据分组重写请求路径
    if (group === 'A') {
      url.pathname = '/page-a';  // 假设A版本路径
    } else {
      url.pathname = '/page-b';
    }

    // 向源站发起请求
    const response = await fetch(url, request);

    // 如果是新分配的用户，设置Cookie
    if (!match) {
      const newResponse = new Response(response.body, response);
      newResponse.headers.set('Set-Cookie', `ab_test_group=${group}; Path=/; Max-Age=86400; HttpOnly; SameSite=Lax`);
      return newResponse;
    }

    return response;
  }
};

解释代码逻辑

• 获取Cookie：从请求头中找出 ab_test_group 的值。如果存在，直接使用；如果不存在，用 Math.random() 公平分配A或B。
• 路径重写：将原始URL的路径改成对应版本的路径。注意：你需要确保源站上有 /page-a 和 /page-b 两个资源。
• 设置Cookie：当用户第一次访问时，通过 Set-Cookie 让浏览器记住分组，有效期设为1天（Max-Age=86400）。后续访问时便不会重新分配。
• 转发请求：用 fetch(url, request) 把改写后的请求发往源站，这样源站收到的就是 /page-a 或 /page-b，完全不知道有A/B测试这回事。

部署与验证

1. 在Cloudflare Dashboard的Workers页面粘贴代码并部署，选择一个路由（比如 www.example.com/*）。
2. 用浏览器的无痕模式访问你的首页，打开开发者工具查看网络请求。你会看到响应头中出现了 Set-Cookie: ab_test_group=A 或 ab_test_group=B。
3. 刷新页面（不关标签页），由于Cookie已存在，分组不变。
4. 清空Cookie重新访问，会有50%概率分配到另一个版本。

关联教程：此处可内链到“CDN Edge部署与验证”内容。

Edge Side A/B测试的优势与风险

优势

• 零后端侵入：源站不需要任何改动，静态站点也能做A/B测试。
• 零客户端闪烁：由于边缘节点直接返回不同的HTML，浏览器从一开始就只收到一种版本，没有JS切换造成的视觉抖动。
• SEO友好：爬虫请求时如果也经过CDN，可以通过判断User-Agent或其他方式绕过Cookie分组，或者统一返回默认版本，避免被判定为“伪装内容”。
• 近乎零延迟：边缘计算节点通常离用户较近，执行时间在毫秒级，几乎不影响TTFB。

风险与注意事项

• 缓存干扰：如果CDN缓存了页面，可能导致不同分组的用户看到相同内容。解决方法：在URL中加入分组参数（如 ?v=a）或者根据Cookie动态设置 Cache-Control: private，让CDN不缓存该页面。但注意，这会影响性能。更优的做法是让边缘计算直接返回不同URL的响应，利用CDN的缓存机制将两个版本分别缓存。
• 分组持久性：Cookie有过期时间，但如果用户清除了Cookie或换了设备，会重新分配分组。对于需要长期跟踪的实验，最好结合用户登录状态（如通过JWT中的用户ID），但这就超出了纯边缘计算的范畴。
• 成本：免费额度一般够用，但如果请求量很大（比如上亿次/月），Workers的费用可能比传统后端高。需要评估。
• 调试困难：边缘计算代码运行在分布式节点上，日志和监控不如后端方便。建议在实验初期增加一些请求头（如 x-ab-group）以便通过浏览器开发者工具确认分组。

进阶：Cookie路由与多变量实验

先看关键判断

上面的例子只有两个版本，实际业务中你可能需要同时测试多个变量（比如标题、按钮颜色、图片位置的组合）。Cookie路由同样可以扩展：

• 使用一个JSON格式的Cookie，例如 ab_variants=%7B%22title%22%3A%22b%22%2C%22button%22%3A%22a%22%7D（URL编码后），边缘计算代码解析出每个变量，然后在响应中动态修改对应的HTML片段。不过动态修改HTML比较重，更常见的做法是预先在源站生成多个组合的静态页面，比如 /title-b/button-a/index.html，让边缘计算根据Cookie里的组合映射到对应路径。

这样，你的实验可以轻松扩展到几十个版本，而源站依然只是静态文件服务。

补充参考：此处可内链到“CDN Edge故障排查实例”。

什么时候不适合用这种方法？与CDN Edge

我的处理经验

• 如果A/B测试需要实时个性化（比如根据用户当前行为动态调整），边缘计算可能不够“智能”，因为每个请求都需要执行一段固定逻辑。
• 如果实验涉及后端业务逻辑（比如不同的支付流程），边缘计算无法处理动态数据，必须让后端介入。
• 如果网站已经用了某种重型前端框架，并且A/B测试需要改变组件状态，可能还是JS方案更灵活。

大部分内容型网站、营销页面、落地页，非常适合采用Edge Side A/B测试。

想继续深入：此处可内链到“CDN Edge优化清单”文章。

总结

容易忽略的细节

通过CDN边缘计算实现无服务器A/B测试，本质上就是把“决定用户看哪个版本”的权力从后端服务器移交到CDN节点。你用最少的代码、最小的侵入性，完成了让不同用户看到不同内容的任务。Cookie路由是其中最简单直接的方式：用户的分组信息被存储在Cookie中，边缘节点读取后执行路径重写或内容改写。对整个技术栈的要求极低——你甚至不需要一台后端服务器，只要有一个静态文件托管服务（如对象存储）即可。

对于刚接触这个领域的小白，建议先跑通上面Cloudflare Workers的例子，感受一下“边缘”的力量。当你发现只需几十行代码就能在全球范围做A/B测试时，你会重新思考“实验”这件事的成本和可能性。把这些步骤跑通后，CDN Edge基本就能稳定落地。

延伸阅读

• CDN边缘计算上的无服务器GraphQL网关设计原理
• 边缘动态渲染：CloudFront+Lambda@Edge对比评测
• 边缘节点新玩法：语义识别GraphQL POST请求并智能缓存