配置 CDN动态内容缓存绕过条件与配置，先别急着选规则类型：要判断同一份响应能否安全地提供给不同访问者。以 WordPress 站点为例，公开文章适合评估共享缓存，管理页面和含个人数据的接口则应避免被公共缓存。路径、参数、请求头分别适合不同的边界，选错可能让页面串用户，也可能让本可复用的内容每次都回源。
先划分响应：哪些能共享，哪些不能
把请求按响应是否因访问者身份而变化分成两类。公开文章、公开分类页通常可供多人读取；账户资料、登录后的管理界面可能包含身份相关内容，应绕过公共缓存，或使用经过审慎设计的私有缓存策略。判断时不能只看页面名称，还要检查响应正文、状态码和响应头是否会随身份、语言或筛选条件改变。
绕过规则不是越多越安全：规则过宽会降低命中率，增加源站请求；规则过窄则可能缓存不该共享的响应。CDN动态内容缓存绕过条件与配置应围绕实际业务边界，而不是把所有动态请求统一处理。
三种方式各自适合什么情况
路径：按功能区域划界，容易审查
当敏感功能集中在固定目录或文件时，路径规则最直观。WordPress 的 /wp-admin/ 和 /wp-login.php 可作为检查对象；具体是否绕过仍要结合站点改写规则和响应内容确认。优点是规则易读、对查询参数变化不敏感；缺点是路径设计不统一时容易漏项，按整个 /api/ 绕过也可能连公开接口一起排除。
查询参数：只处理真正改变内容的参数
搜索词、分页号或筛选条件若会改变结果，就应进入缓存键，或针对这类请求设置绕过；仅用于统计来源的参数，若确认不影响响应，可以在缓存规则中忽略。不要无差别忽略全部参数，否则不同搜索结果可能命中同一缓存；也不要把每个追踪参数都纳入缓存键，否则会产生大量低复用副本。
请求头：用于身份或表示差异明确的场景
请求携带 Authorization 且响应按用户身份变化时，通常应绕过公共缓存。若响应只是按 Accept-Language 选择语言，则可以考虑将语言纳入缓存键，而非直接绕过全部请求。请求头规则表达能力强，但要确认源站确实依据该头改变响应；无关头被纳入缓存键会降低命中率。
按这个顺序落地并验证
- 列出响应边界：记录页面或接口是否含账户信息、是否受查询参数影响、是否按请求头变化。
- 优先写窄规则：用明确的敏感路径处理登录与管理功能；对查询参数采用允许列表或明确的参数匹配；只对确实影响身份的请求头设置绕过。
- 设置缓存键：把会改变公开响应的参数或语言纳入键；确认统计参数可忽略后再排除。不同 CDN 控制台的规则名称和优先级可能不同，应核对其缓存键与绕过规则的执行顺序。
- 双身份、双条件测试：分别用未登录与已登录状态请求同一路径，再改变筛选参数或语言头，检查响应正文及缓存状态。确认个性化内容没有被另一身份复用，公开内容的差异条件也没有被错误合并。
- 观察后再调整：检查命中率、回源量和源站日志。公开且更新不频繁的内容可从几十秒到数分钟评估缓存时间；更新频繁或错误代价高的内容应缩短时间或绕过，具体取决于更新速度与业务容忍度。
常见问题
路径规则和请求头规则能同时使用吗？
可以。先用路径划出敏感区域，再用身份请求头补充判断；需确认规则优先级，避免宽泛的缓存规则覆盖绕过规则。
带查询参数的请求都应该绕过吗？
不必。只要区分会改变响应的参数与纯追踪参数，并正确设置匹配和缓存键即可。
怎么判断配置是否安全？
用不同登录身份及不同参数重复请求，比较响应正文和缓存状态；同时查看源站日志，确认敏感请求确实回源。
最终选择取决于差异出现在哪里：路径稳定时优先按路径划界，内容由少数参数决定时精确处理参数，身份或表示随请求头变化时再针对请求头配置。把这些边界逐项验证，才是可维护的 CDN动态内容缓存绕过条件与配置。
