商品详情页可以缓存，购物车和个人资料页通常不能直接复用同一份响应。配置 CDN动态内容缓存绕过条件与配置，关键不是把整站设为不缓存，而是识别哪些请求依赖用户身份、实时状态或提交操作，再让规则按预期生效。
先判断内容是否能被多个用户共享
判断标准是：同一 URL 在不同用户或不同时间请求时，响应内容是否必须不同。登录后的账户页、购物车、订单状态和个性化推荐，常与会话或用户身份有关，通常应绕过共享缓存，或采用经过验证的独立缓存键。公开商品说明、通用帮助页面则可能适合缓存，但仍要考虑更新频率。
还要区分“绕过缓存”和“禁止存储”。绕过通常表示符合条件的请求不读取 CDN 缓存，并转发至源站；响应是否会被缓存，还受源站响应头和 CDN 规则影响。若要求浏览器及中间缓存也不要保存敏感响应，应检查源站的 Cache-Control，不能只依赖 CDN 的绕过规则。
把请求特征变成明确条件
检查路径、方法与查询参数
优先按明确路径匹配，例如将账户、购物车、结算等动态路径设为绕过，而不是对所有页面禁用缓存。GET、HEAD 常用于读取内容；POST 等提交方法通常不应套用普通页面缓存规则，但具体行为取决于 CDN 产品和站点配置。查询参数也要逐项确认：跟踪参数可能无需进入缓存键，筛选或分页参数若会改变页面内容，就不能随意忽略。
检查 Cookie 和请求头
若源站依据会话 Cookie 返回用户专属内容，可针对必要的 Cookie 设置绕过条件。不要简单地让所有 Cookie 都改变缓存键：Cookie 种类多时，可能造成缓存碎片和命中率下降。响应头 Set-Cookie 也值得检查；它说明响应设置了 Cookie，但是否阻止 CDN 缓存，要看平台默认行为和显式规则，不能假定所有 CDN 都会采取相同处理。
请求头条件同样要谨慎。只有当某个头确实改变响应内容时，才考虑把它纳入缓存键或用作绕过条件。Vary 可表达响应随哪些请求头变化，但 CDN 是否按该头区分缓存，需以其产品配置为准。
按顺序配置并验证优先级
- 列出页面类型。记录路径、请求方法、是否依赖登录态、会影响内容的 Cookie、查询参数及请求头。
- 先写窄规则。为账户、购物车等明确动态路径设置绕过；保留公开静态内容的缓存规则。避免用一个宽泛条件覆盖全站。
- 检查规则顺序。确认后执行的宽泛缓存规则不会覆盖前面的绕过规则；不同 CDN 对优先级、首条匹配或规则合并的处理可能不同，应查看对应控制台说明。
- 核对源站响应头。检查 Cache-Control、Set-Cookie 和 Vary，并确认 CDN 对这些头的实际处理方式。
- 分别测试两类请求。用未登录与已登录会话请求同一路径，核对响应内容、缓存状态及请求是否回源；再测试不同参数和提交方法。测试时不要把真实敏感信息写入共享日志或示例链接。
- 小范围发布后复查。观察动态页是否仍被错误缓存、静态资源命中是否异常下降；必要时清理受影响对象，再调整规则。
常见配置误区
把整个域名都设为绕过，配置简单，却会让可缓存的公开页面也频繁回源。把完整 Cookie 放进缓存键，可以隔离不同会话，但高基数 Cookie 会显著拆分缓存。仅依据请求带有 Cookie 就绕过则较稳妥，但若大量匿名访问也携带无关 Cookie，仍可能降低缓存利用率。选择时应以内容是否个性化、错误共享的风险和源站承载能力为依据。
因此，CDN动态内容缓存绕过条件与配置应从内容差异出发，再落实到路径、方法、Cookie 和请求头，并核实规则优先级与响应头。先覆盖明确的用户专属页面，再逐步测试例外，比直接关闭整站缓存更容易控制风险。
常见问题
带 Cookie 的请求一定要绕过吗？
不一定。若 Cookie 不影响响应，未必需要绕过；若它代表登录会话且页面因用户而异，应绕过或采用经过验证的隔离方案。
设置绕过后还要改源站响应头吗？
视目标而定。绕过 CDN 不等于禁止浏览器存储；敏感响应通常还应检查 Cache-Control 等响应头。
为什么规则配置后仍看到缓存命中？
可能是规则顺序、匹配条件、缓存键或平台处理方式与预期不同。应使用实际请求逐项核对匹配结果和缓存状态，并确认变更已生效。
