AWS CloudFront CDN缓存问题：设置max-age=0后仍触发请求合并转发，无法返回个性化内容

问题根因定位 #

之前的实现方案失效，核心是对CloudFront的缓存机制存在两个典型误解：

• 当边缘节点已经存储了某路径的公共内容时，只要这份缓存还在自身的TTL有效期内，CloudFront会直接返回旧缓存，不会触发回源流程，自然也不会识别到你后续返回的max-age=0缓存头规则。
• 你观察到的请求合并转发（collapse forwarding），是CloudFront为保护源站设计的机制：当某个缓存键的对象需要回源时，短时间内打向这个缓存键的所有请求会被聚合，只发一次回源请求，把响应同步给所有等待的用户。如果聚合流程匹配到的是之前存储的公共缓存，所有请求都会拿到旧的公共内容，根本不会走到源站处理个性化的逻辑分支。

可落地的解决方向 #

1. 搭配正确的缓存头与主动缓存失效 #

• 切个性化场景时，源站返回的缓存头不要只设置max-age=0，要完整配置成Cache-Control: no-cache, no-store, must-revalidate：其中no-cache强制CloudFront每次请求都必须先向源站校验内容有效性，不能直接使用本地存的旧缓存；no-store明确要求CDN不要把本次的个性化响应写入任何边缘缓存层。
• 切模式节点必须主动触发一次CloudFront按需缓存失效，把之前公共内容对应的路径从所有边缘节点清除。这一步没有配置可以替代：CloudFront不会自动感知源站的规则变更，只要旧缓存还在TTL有效期内就会一直返回旧内容，主动失效可以强制所有节点丢弃旧的公共缓存，后续请求自然会回源拿到个性化响应。

2. 调整缓存键规则，从根源隔离两类内容 #

• 不要让公共内容和个性化内容共用同一个缓存键：在CloudFront的缓存键配置中，把区分用户身份的查询参数纳入缓存键维度。切到个性化模式时，每个用户身份会生成独立的缓存条目，之前不包含用户参数的公共缓存条目自然不会被命中，也就不会触发针对旧公共缓存的请求合并流程。
• 不需要全局关闭CloudFront的请求合并机制：只要缓存键做了隔离，哪怕CloudFront对同一个用户ID的请求做合并，最后回源拿到的也是对应用户的个性化内容，不会出现串缓存的问题。

3. 拆分CDN行为配置，完全隔离缓存策略 #

• 直接在CloudFront分发中配置两套独立的路由规则：
  • 公共内容路径：设置较长的TTL，缓存键不包含用户个性化参数，保留请求合并转发能力，最大化降低回源带宽压力；
  • 个性化内容路径：直接在CDN行为配置中设置最小TTL=0、最大TTL=0，关闭所有缓存逻辑，所有请求直接透传到源站。哪怕CloudFront对这类透传请求做合并，也因为没有缓存层存储内容，所有请求都会由源站根据用户身份返回对应响应，不会拿到旧的公共内容。
• 如果不想修改后端业务路径，可以直接用请求查询参数做路由匹配：当请求携带个性化标识（比如personalized=1）时，自动路由到无缓存的行为规则，不带标识的公共请求走高缓存规则，全程不需要调整源站的业务逻辑。

4. 零停机切换的兜底方案 #

• 如果不想每次切模式都手动触发缓存失效，可以给公共缓存增加版本维度的缓存键：比如公共内容缓存时，缓存键关联的版本值为public_v1，切个性化模式时，直接在CloudFront配置中把缓存键的版本值切到personalize_mode，相当于开辟了全新的缓存键空间，之前存储的公共内容因为缓存键不匹配，永远不会被命中。整个过程不需要做缓存失效，只需要调整CDN的缓存键配置就能完成切换，没有流量中断。

内容的提问来源于stack exchange，提问作者Batkiller