策略冗余与冲突检查是什么
当一条策略的匹配条件被排在它前面的策略完全包含时，它就成为永不命中的冗余规则；如果两条规则的动作为放行与拒绝，还可能形成表面上的冲突。这类问题多出现在长期迭代的策略库里：每次上线各加一条，没人整体梳理，实际生效的行为与文档记录逐渐脱节。检查方法是按区域对分组导出规则，做条件维度的包含关系比对，再逐条给出保留、合并或删除的结论。
基本信息
| 常见形态 | 宽泛放行遮挡精细拒绝；两条规则条件完全一致 |
|---|---|
| 发现方法 | 按区域对导出全部规则，做条件包含关系比对 |
| 辅助证据 | 命中计数、日志与业务清单三方印证 |
| 处理原则 | 先重排、再合并、最后删除，每一步都要留档 |
| 风险控制 | 删除前保留观察期与配置备份，明确回退方式 |
典型使用场景
- 年度策略评审：对全量规则做一次系统性的冗余梳理
- 多次变更后核对：新增规则是否被原有宽泛规则遮挡
- 合并同方向规则：把条件相近的多条规则合并以减少条目
- 整改取证：向审计说明策略库已做冗余清理并保留记录
- 新业务上线前：确认新增规则不会被现有规则提前匹配
排查思路示例
排查思路示例
1. 导出全部规则（区域对、源、目的、服务、动作、命中计数）
2. 按区域对分组，按条件宽窄排序
3. 标记被前序规则完全覆盖的条目，区分遮挡与重复
4. 对每条给出保留 / 合并 / 删除结论，业务方确认后执行
5. 处理后重排并留档，观察一个业务周期再清理旧记录三类问题的处置
| 问题 | 判据 | 处置方式 |
|---|---|---|
| 完全重复 | 条件与动作都相同 | 保留一条，删除另一条并留档 |
| 被遮挡 | 条件被前序完全包含 | 重排顺序或并入前序规则 |
| 部分重叠 | 条件区间有交集 | 按业务拆分或调整为互斥条件 |
| 动作冲突 | 相同条件不同动作 | 按业务确认后只保留一条 |
| 零命中但条件独特 | 无遮挡但长期无流量 | 确认业务已下线后再删除 |
删除任何策略前先用命中计数验证其长期为零，并保留配置备份与变更记录：策略删除属于高风险变更，回退依赖备份而不是记忆。