线上常见这样一幕：商品页 /item?id=100 命中 CDN 后，匿名访客拿到了会员价；再加入 campaign 参数，同一商品出现多份缓存，命中率从 90% 掉到 60%，回源流量随之上涨。问题不在“有没有缓存”，而在缓存键能否准确代表响应内容，以及不同权限是否被放进同一条缓存链。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：rabisu（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
第一节：缓存键为何会制造内容副本
缓存键的职责，是把请求映射到正确的响应表示。URL 参数进入键前要做URL参数归一化：utm_medium、gclid 等明确不参与内容生成的跟踪参数可删除；id、sku、lang、theme 等影响输出的参数必须保留。重复参数、顺序和等价路径也要处理，但不能把归一化等同于删参数。数组型参数在不同框架中语义可能不同，贸然去重或重排会改变结果。判断依据是：移除或合并某参数后响应正文是否变化，变化就继续隔离，无变化再规范化。
请求头同样会改变响应。语言、编码、设备类型可按实际差异进入缓存键，也可通过Vary响应头让缓存选择对应变体。但 Vary 并非加上就安全：Vary: Cookie 会让每个会话形成海量副本，Authorization 也不宜完整入键。公共响应可共享缓存，鉴权内容则应使用独立缓存区、私有策略或绕过 CDN，避免内容串用与权限泄露。
第二节：用响应差异判断缓存键粒度
判断键粒度，可建立“请求特征响应差异”矩阵。至少组合匿名、会员、主题和语言，检查状态码、价格字段、权益标识与正文哈希。若两个请求仅因登录状态返回不同数据，就属于鉴权响应隔离问题，不能因 URL 相同而共用缓存。测试时可用随身服务器准备不同登录态，验证 CDN 实际命中的对象，而不只观察源站返回。
再检查参数是否漏进键或污染内容。随机时间戳、一次性令牌、会话 ID 会让每次请求成为新键，表现为回源激增、缓存体积却不涨。应按令牌作用域设置短 TTL、私有缓存，或在令牌失效后允许复用无敏感信息的响应。反过来，商品状态或价格已更新，而 URL 和键未变，旧对象仍会被服务；可用内容版本号、精确清理或 surrogate key 定向失效，避免全局刷新打穿命中率。
最终按三问验收：不同身份是否拿到各自响应，无关参数是否不再制造副本，内容更新后旧版本能否及时退出。缓存键粒度不是越细越好，而是让内容更新失效只影响真正变化的变体。
缓存键粒度与响应隔离
缓存键决定请求能否复用已有响应。粒度过粗会把个性化内容串给其他用户，过细又会制造大量低命中对象。应保留影响正文的参数，如资源版本号、语言和商品规格；埋点参数、分享来源等不影响内容的参数可在边缘侧剔除。参数顺序或重复值可能具有业务含义，不能直接排序或去重。
URL 参数归一化应统一协议、主机名、默认端口、百分号编码和空值规则。主机名大小写通常可归一，路径大小写却不能擅自转换；id=1 与 id=01 是否等价，应由接口定义，而非 CDN 猜测。同一规则要用于缓存键生成和回源请求，避免边缘与源站对同一 URL 得出不同结果。
鉴权响应隔离要求私有内容退出共享缓存，通常返回 Cache-Control: private, no-store；若 CDN 支持自定义缓存键，可绑定安全的用户或租户作用域，不能直接依赖 Authorization 原文。Vary 响应头用于声明响应还受哪些请求头影响，例如 Accept-Encoding。Vary: Cookie 会显著扩大键空间，应慎用。上线前要用不同用户、编码和参数组合实测，确认不会串缓存。
内容更新失效与上线检查
内容更新后，旧对象可能仍在边缘节点。发布路径应优先使用版本化 URL，让新对象自然形成新缓存键；URL 无法变化时，再使用主动刷新或缓存标签清理。关键内容可采用软清理并按需回源，但要设置最大陈旧时间；源站应让失效资源返回 404 或新对象，防止清理结果再次被缓存。
常见坑包括只刷新源站、漏刷部分节点、刷新后遭遇回源洪峰，以及把短 TTL 当作可靠失效方案。高热内容可使用 stale-while-revalidate 渐进更新，并配置回源限速与并发保护。监控除命中率外，还应观察缓存键数量、刷新时延、回源率和 4xx/5xx 比例。
最终执行检查清单：①列出影响正文的参数及可删除参数；②固定协议、主机名、编码、大小写和重复参数规则；③核对 Vary 与真实响应差异一致，私有响应不进入共享缓存；④用不同用户、请求头和参数组合做串缓存测试；⑤验证版本化、主动刷新、源站兜底三条发布路径；⑥压测刷新后的回源峰值；⑦为命中率骤降、刷新失败、响应不一致和权限泄漏配置告警，并保留回滚方案。
喜欢 
顶
难过
囧
围观
无聊
