折腾AWS CloudFront时，我发现最麻烦的往往不是安装，而是配置。做网站优化、改版或上新功能，AB测试几乎是必经之路。但很多站长和开发者发现，传统AB测试方案——无论是后端渲染两个版本，还是前端 JavaScript 动态切换——都会带来一个头疼的问题：页面加载变慢了。如果因为做实验让用户体验下降，那实验数据本身也失去了意义。有没有一种办法，既能精准分流，又几乎不增加延迟？答案藏在 CDN 边缘节点里。
AWS CloudFront：AB测试为什么必须考虑延迟
容易忽略的细节
AB测试本质上就是把用户随机分成两组，一组看到旧版本（对照组），一组看到新版本（实验组），然后比较两组的关键指标。传统做法通常有两种：
- 服务端方案：请求到达源服务器后，后端根据用户 ID 或 Cookie 决定返回哪个版本。缺点是每个请求都要完整走一遍源站，如果源站距离用户远，延迟天然就高。
- 客户端方案：先返回统一的页面，然后在前端用 JavaScript 切换元素或样式。优点是服务器压力小，但用户必须先下载原始页面再变，容易造成内容闪烁（Flash of Original Content），而且对于首屏性能影响大。
这两种方案在延迟敏感的场景下都不理想。尤其是电商、资讯、工具类网站，每多 100 毫秒加载时间，转化率就可能下降几个百分点。我们需要一种在用户请求到达源站之前就能做出分流决策的架构——这就是边缘计算适合的任务。
延伸阅读：此处可内链到“AWS CloudFront配置案例”相关文章。
什么是边缘计算和 CloudFront Edge Functions
故障定位思路
边缘计算就是把计算能力放到离用户最近的地方，比如 CDN 的节点服务器上。AWS CloudFront 提供了两种边缘函数：
- CloudFront Functions：轻量级 JavaScript 环境，适合做简单的请求/响应修改，最大执行时间 1 毫秒，代码包小于 10 KB。只能运行在查看器事件（Viewer Request / Viewer Response）。
- Lambda@Edge：功能更强大，能访问外部网络和 AWS 服务，执行时间最长 30 秒，但启动延迟稍高。可以运行在查看器事件和源请求/响应事件。
对于 AB 测试这种逻辑：判断用户属于哪个实验组，然后修改请求头（例如添加一个版本标识）或者直接返回不同的内容，CloudFront Functions 完全够用，而且延迟最低（微秒级）。
边缘AB测试的核心原理
我的处理经验
想象一下用户访问你的网站：他请求一个 URL（比如 https://example.com/landing）。这个请求会先到达最近的 CloudFront 边缘节点。此时，如果我们在节点上挂载了一个 CloudFront Function（查看器请求事件），函数就能在请求到达源服务器之前执行判断。
判断的依据通常有两种：
- Cookie 分流：用户第一次访问时，函数生成一个随机实验分组（比如 50% 概率分到 A 组，50% 分到 B 组），把分组信息写入 Cookie，同时修改请求路径或查询参数，让源站或 CloudFront 缓存返回对应版本。
- URL 参数分流：如果不想依赖 Cookie（比如某些接口不支持），可以将实验参数直接加到 URL 里，但需要确保实验分组的一致性。
更优雅的做法是：函数根据用户特征（例如 User-Agent 或 IP 段）计算哈希，决定分组，然后将分组 ID 插入请求头（如 x-experiment-group: A）或者重写 URL。源服务器或 CloudFront 的缓存策略根据这个分组 ID 缓存不同的版本。
想继续深入：此处可内链到“AWS CloudFront优化清单”文章。
一个简单的部署思路（面向小白）
第一步：准备 CloudFront 分配
你只需要一个正常运行的 CloudFront 分配，后端可以是 S3、EC2 或者任何 HTTP 源站。
第二步：编写 CloudFront Function
函数代码很简单，大致逻辑如下（伪代码风格，仅示意）：
function handler(event) {
var request = event.request;
var cookies = request.cookies;
// 检查是否已有实验分组 Cookie
if (!cookies['experiment']) {
// 随机选择 A 或 B
var group = Math.random() < 0.5 ? 'A' : 'B';
// 写入 Cookie（告诉浏览器保存分组信息）
request.cookies['experiment'] = { value: group };
} else {
var group = cookies['experiment'].value;
}
// 将分组信息传递到源站，例如添加一个请求头
request.headers['x-experiment-group'] = { value: group };
return request;
}注意：CloudFront Functions 的 Cookie 操作需要遵守格式，实际部署时需参考官方文档。而且函数只运行在查看器请求事件，不影响后续缓存。
第三步：配置源站响应不同版本
当源站收到带有 x-experiment-group 头的请求后，就可以根据这个头返回对应的 HTML。例如，Nginx 或应用服务器读取该头，返回不同版本的页面。
第四步：处理缓存
AB 测试最怕缓存污染：同一 URL 缓存了 A 版本，却让 B 版本用户看到了。解决方案是让 CloudFront 根据 x-experiment-group 头作为缓存键的一部分。在 CloudFront 行为配置中，开启“基于选定请求头的缓存”，将 x-experiment-group 添加为缓存键。这样 A 组用户请求的 URL 会被缓存为一份，B 组用户请求的同一 URL 会被视为不同的缓存对象。
为什么边缘AB测试能保持低延迟
验证与回滚
整个过程发生在 CDN 边缘节点，用户请求被函数处理的时间通常在 1 毫秒以内，然后请求直接转发到源站或者从 CloudFront 缓存返回。相比传统方案：
- 没有额外的 DNS 或重定向开销：分流决策就在 CDN 节点上完成。
- 无需额外部署实验服务器：边缘函数就是你的实验控制器，不需要专门起一个服务来做分流。
- 源站负担减轻：如果两个版本的静态资源可以缓存在 CDN，源站只需要生成一次。
对于全球用户，边缘节点离用户越近，效果越明显。如果你的源站只在美国，而亚洲用户访问通常要绕半个地球，边缘分流可以直接让亚洲用户从亚洲边缘节点拿到结果。
补充参考：此处可内链到“AWS CloudFront故障排查实例”。
进阶阅读：此处可内链到“AWS CloudFront性能优化”指南。
需要注意的坑和局限性
验证与回滚
边缘 AB 测试不是万能的，以下情况需要谨慎：
- 逻辑复杂度限制：CloudFront Functions 无法执行复杂的数学运算或调用外部 API。如果你需要基于用户画像、历史行为等做精细化分流，需要使用 Lambda@Edge 或结合 DynamoDB。
- Cookie 和缓存一致性：如果用户清除 Cookie，实验分组会丢失，用户可能切换到另一个版本。对于长期实验，建议将分组 ID 存储在用户登录态中（后端控制），或者使用持久化方案。
- 实验分组随机性：简单随机可能造成抽样不平衡。更严谨的做法是使用哈希分桶，保证用户始终进入同一组，且组间用户数量稳定。
- 运行时间限制：CloudFront Functions 最长 1 毫秒，如果代码复杂可能会超时。好在判断分组逻辑通常很简单，一般不会超。
另外，在生产环境上线前，务必在测试分配上验证：缓存键是否正确、分组是否均匀、不同版本的内容是否正常等。
总结：什么时候该用边缘AB测试——AWS CloudFront
容易忽略的细节
如果你的网站对性能要求高，AB 实验流量大，或者源站分布在单一区域但用户遍布全球，边缘 AB 测试是一个性价比很高的选择。它利用了 CDN 的天然优势，把分流的计算压力分散到边缘，换来几毫秒到几十毫秒的延迟优化。结合 CloudFront Functions 的轻量和快速，即使是小型团队也能在几分钟内搭建起实验框架。
当然，如果实验逻辑复杂、需要实时数据交互，或者团队已经有一套成熟的服务器端实验平台，不一定非要迁移到边缘。技术选型永远要匹配场景。但了解这种思路，能让你在做延迟优化时有更多灵活的工具。
最后，记住 AB 测试的核心目标是验证假设，而不是为了炫技。在保证数据准确的前提下，给用户最快的体验，才是好实验。把这些步骤跑通后，AWS CloudFront基本就能稳定落地。
延伸阅读