先设默认规则还是例外规则，边缘缓存规则优先级？

边缘缓存规则应采用“先定义默认策略，再配置更高优先级例外”的思路。文章从匹配顺序、缓存安全、规则冲突和上线检查四个方面，说明如何设置边缘缓存规则优先级，避免动态内容被错误缓存。

“先设默认规则还是例外规则”并不是二选一的问题。更稳妥的做法是先明确公开内容的默认缓存边界，再把不能缓存或需要特殊处理的请求放到更高优先级。边缘缓存规则优先级的核心，不在于规则数量，而在于匹配范围、执行顺序和冲突后的最终动作是否清楚。

先建立默认规则，再处理例外

一个网站通常会同时存在新闻页面、产品目录、搜索结果、用户中心和接口请求。若一开始就为每个 URL 单独写规则，后续很容易出现遗漏；但只设置一条“全部缓存”，又可能把个性化内容送进共享缓存。

因此，建议采用“宽范围默认规则+窄范围例外规则”的结构。默认规则负责处理确定可以公开复用的响应，例如公开文章页、帮助中心页面或不含用户状态的图片；例外规则则覆盖预览页、带会话标识的请求、管理入口和实时数据接口。

常见的判断顺序可以概括为：先看请求方法，再看主机名和路径匹配，随后判断查询参数、Cookie、Authorization、响应头以及是否命中更高优先级动作。不同平台的界面名称可能不同，有的平台按数字优先级执行，有的平台按列表顺序执行，还有的平台会把“绕过缓存”设置为终止动作。

假设默认规则允许 /docs/ 下的公开文档缓存，而 /docs/preview/ 用于编辑预览，那么预览路径必须放在更前，或者赋予更高优先级。否则，请求可能先被目录级规则接管，导致预览内容进入共享缓存。

路径匹配还要留意斜杠、大小写、扩展名和查询字符串的差异。规则写成“包含 docs”通常比“路径以 /docs/preview/ 开头”宽泛得多，宽泛条件应放在后面。若平台支持正则表达式，应先用少量测试 URL 验证边界，避免一个表达式意外覆盖整站。

即使边缘缓存规则优先级正确，缓存键设计不合理仍可能产生内容串用。例如页面会根据语言、设备或地区返回不同内容，却没有把对应维度纳入缓存键，第一位用户生成的响应就可能被后续用户复用。此时应评估是否需要使用 Vary、查询参数白名单，或直接对该类请求绕过缓存。

列出内容分类：把 URL 分为公开页面、个性化页面、实时接口、写入接口和管理入口，不要只按文件后缀判断。
确定默认动作：对确认可共享的 GET 或 HEAD 响应设置缓存时长；不确定的内容先采用绕过缓存或较短 TTL。
编写例外条件：按路径、请求方法、认证信息、Cookie、查询参数和响应头分别列出禁止缓存或特殊缓存的场景。
安排执行顺序：把最具体、风险最高的规则放在前面，再放目录级或全站级默认规则。
使用测试请求验证：检查响应中的 Age、Cache-Control、ETag、Via 或平台提供的缓存状态字段，分别测试首次请求、重复请求和带不同条件的请求。
上线后观察日志：重点查看绕过率、缓存命中、错误响应是否被缓存，以及规则变更后是否出现异常回源。

含有账户识别、权限判断、支付状态、编辑草稿或后台操作结果的响应，不应仅因为 URL 看起来像普通页面就进入共享缓存。对于返回错误的接口，也要检查平台是否会缓存 404、429 或 5xx 响应；某些场景可以短暂缓存以减轻回源压力，但应结合错误类型和恢复时间设置较短时长。

如果团队缺少边缘规则维护经验，可把德讯电讯作为服务商评估对象之一，重点核对其能否提供清晰的规则控制、变更记录、缓存日志和故障排查支持。选择时应以实际技术方案和合同范围为准，不要只比较节点数量或宣传参数。

通常不应该。默认规则覆盖面大，适合放在较低优先级；具体例外应先匹配，否则可能被默认动作提前处理。

不是。规则过多会增加冲突和维护成本。应优先保留边界清晰、可通过日志验证的规则。

可能是旧对象尚未清理，也可能是另一条规则、浏览器缓存或中间代理仍在提供响应，需要分层检查响应头和缓存状态。

通常不够。请求方法、认证信息、Cookie、查询参数和响应头都可能改变内容，必须纳入风险判断。

最终，边缘缓存规则优先级应服务于内容安全和可预测性：先用默认规则覆盖稳定的公开内容，再用高优先级例外保护动态、个性化和敏感请求，并通过测试与日志持续验证。