Cache Rules可按匹配顺序叠加：不同设置可以同时生效，同一设置冲突时以最后一条匹配规则的值为准。同路径存在旧Page Rules时，Cache Rules优先；如果有Workers参与，还需核对它是否覆盖了缓存行为。
把同一请求会匹配的规则列在一起
固定目标URL、方法、Cookie和参数，列出命中的Cache Rules，按面板中的实际顺序记录各规则设置了什么。规则名称不是表达式：叫“登录绕过”的规则若条件过宽，也可能命中商品页。TTL、缓存资格和缓存键应分列，不能只写一项“缓存开启”。
逐项判断叠加和最后覆盖
例如第一条设置Edge TTL，第二条只设置缓存键时，两项可共同生效；若前后规则都设置缓存资格，后面匹配规则的值覆盖前面的值。后面的规则没有配置某个设置，不代表它会把前面所有设置恢复默认。因此，要逐个属性计算，而不是仅判断最后命中的规则名称。
检查Page Rules与Workers的干预
Cloudflare官方明确同路径缓存冲突时Cache Rules优先于旧Page Rules；Workers设置也可能改变最终缓存行为，需结合当前实现及兼容要求核对。不要用WAF的动作逻辑套用缓存规则。账户具备Trace等诊断能力时，用固定样本查看匹配链；否则保留规则与响应对照。
清理受影响副本后重新请求
调整规则不等于已缓存内容立刻失效。按实际改动范围清理相关副本，再用相同条件检查缓存状态和返回内容。另用登录、购物车与会话样本确认应绕过的路径仍未被误缓存，避免修一张公共页面时扩大敏感内容的共享范围。
关键区别
不同设置：匹配规则可叠加；未设置不等于清空。
同一设置冲突：最后匹配的值优先；按具体属性判断。
其他缓存入口：Page Rules与Workers；需核对产品优先级。
怎样确认处理到位
固定请求的命中顺序和每个最终设置都能解释，清理后响应符合预期；不应共享缓存的登录、购物和会话路径仍按规则绕过。
容易误判的边界
缓存规则与安全、重定向规则属于不同处理机制。涉及Workers时不能只根据Cache Rules面板推断最终结果，已有缓存副本也要单独处理。
