上个月有个客户排查审核驳回，发现他干了一件事：把所有带 Googlebot、bingbot 的爬虫 UA 都写进放行规则，当时他感觉这样最稳。结果问题就出在这儿。UA 规则配置里的包含模式把不少真实访客的无头浏览器、还有部分 WebView UA 也一起放进了标准页，偏偏审核抓取请求的新版 UA 不在清单里。所以 UA 规则包含与排除模式怎么选，说白了不是看经验，是看访客构成和审核风险。
这里先别急着下结论，我们一段一段拆开。
包含模式适合哪些前提
所谓包含模式，说白了就是请求命中你指定的 UA 列表，就进标准页分支；没命中，就走默认完整页分支。适合它的前提，我觉得要同时满足几个：投放平台只有一到两个；审核抓取请求的 UA 集合比较固定；团队没有专门人力频繁维护规则。另外，如果真实访客里无头浏览器或应用内嵌 WebView 占比很低，包含模式的误伤范围就可控。
反过来，不适用的情况也很清楚：投放平台超过两个、UA 更新频繁、真实访客 UA 与审核抓取 UA 重合度高。我见过一个做金融教育的客户，只配了 Google 的几条 UA，漏了 TikTok 新版审核抓取 UA，结果页面版本返还不符合预期，连续两次审核驳回。下一步检查动作是：拉最近七天访问日志，按 UA 去重，统计未命中请求里有没有出现平台来源域名。只要出现，就说明清单滞后了，要补录，或者考虑切到排除模式。
排除模式什么时候更合适
排除模式是反过来：先把明确属于真实访客的 UA 从标准页分支里摘出去，剩下的请求再进后续判断。适合它的前提是：真实访客 UA 里有一小部分跟审核抓取 UA 相似，但特征足够明确，比如带 HeadlessChrome，或者某些 Android WebView 标识；还有一种情况是投放渠道多，需要按不同渠道定制分支，规则由脚本批量生成。
这个模式不适合运维能力弱的团队。这里容易搞混——排除条件如果写得太宽，可能把正常审核抓取请求也一起排除出标准页分支；如果长期不更新排除清单，又容易漏掉新出现的无头 UA。下一步检查：审计最近三十天审核抓取请求的 UA 变化，确认排除规则没有误伤这些来源。要是发现审核域名出现在被排除的 UA 里，别犹豫，立即收窄条件或改用混合模式。
混合模式与规则短路顺序
实际投放中不一定非要二选一。我的习惯是，先排除已知真实访客的无头 UA，再用包含模式兜底审核抓取请求。这里要特别注意规则短路顺序：如果排除条件先命中了某个关键字，后面的包含条件可能永远不执行。比如规则先排除了所有带 Chrome 的 UA，那么包含一条审核抓取 UA 里带 Chrome 的规则就会失效。
下一步检查：在命中日志里标注是哪一条规则先捕获请求，核对其优先级是否符合预期。规则短路顺序调优的细节可以参考站内这篇 规则短路顺序调优。若发现短路导致漏判，调整条件顺序，把更具体的审核抓取 UA 放在前面，把宽泛的排除条件放到后面。
一个金融教育组的调整过程
讲个具体例子，这个例子我印象很深。某金融教育混合投放团队，日均点击一千二三，Google 和 TikTok 双渠道。最初用包含模式只配了 Googlebot 两条 UA，TikTok 审核抓取请求的新版 UA 未命中，直接进入完整页分支，连续两次收到审核驳回。后来改为先排除真实访客里明确的 HeadlessChrome 和 Android WebView 标识，再包含两家平台的审核抓取 UA，并每周从日志导出未命中 UA 做审计。调整后没有新增驳回，真实访客进入完整页的比例恢复正常。类似抓取 UA 错配的排查路径可看这篇 UA错配排查思路。
小结
选择包含还是排除模式，判断次序一定是先看访客 UA 分布，再看审核风险，最后看运维能力。先别急着套包含模式，也不要迷信排除模式一劳永逸。两类模式的边界会随平台 UA 更新和投放渠道变化而移动，日志审计才是长期稳定的基础。
常见问题
UA规则包含模式会漏掉新版审核抓取请求吗？
会。包含模式依赖清单完整性，平台更新抓取 UA 后旧清单不会命中。建议每两周核对一次访问日志中未命中 UA，发现来源域名为平台域名时及时补录。
排除模式配置的条数多了会拖慢响应吗？
不会明显拖慢。几十条到上百条 UA 前缀匹配耗时很低，真正影响延迟的是复杂正则和规则短路顺序不当。优先使用固定字符串前缀匹配。
UA规则是否要与缓存键联动？
需要。若页面版本依赖 UA 规则，反向代理或 CDN 缓存必须把 UA 纳入缓存键，否则同 URL 下不同 UA 的访客可能命中同一份缓存，造成版本串用。
延伸阅读
想进一步理清斗篷技术在风险和收益之间的边界，可读这篇投入价值评估：斗篷技术投入到底值不值的风险清单
