更换 Clash（mihomo）规则仓库，审查的是新内容能否继续按本页 rules 语法读入，而不是仓库名称或下载方式。需要逐行看类型名、载荷形态、出站位置、逻辑括号，以及 RULE-SET 名称是否仍能对应 rule-providers。格式变化若使某一行离开类型小节的示例，就不能假定旧配置仍然成立。
适用条件
适用于替换主配置 rules 列表、更换 RULE-SET 所引用的集合，或两份列表合并之后。审查单位是每一条「类型,载荷,出站[,附加参数]」，外加逻辑规则与 SUB-RULE 的括号。不适用于把仓库切换本身当成优先级问题：匹配顺序仍是从上到下，顶部高于底部，但顺序正确并不能挽救错误载荷。若新仓库给出无类型名的纯域名或纯 IP 行，应视为尚未变成可写入 rules 的格式，必须先对照类型列表改写或改为合法的 RULE-SET 引用。
对照类型名与载荷形态
把新旧各取若干行并排，只比较格式，不比较策略偏好：
- 类型是否仍是文档中的名称。
IP-CIDR6可作为IP-CIDR别名保留；其他近义拼写不在列表中。 - 载荷是否仍属于该类型：完整域名、后缀、关键字、仅
*和?的通配、正则、Geosite 名、CIDR、IP 后缀、ASN、国家代码、端口范围、入站类型/用户名/名称、进程路径或名称、tcp/udp、Linux UID 等。注意DOMAIN-SUFFIX的后缀规则与完整DOMAIN、GEOSITE不能对调；GEOIP是 IP 国家代码，不是 Geosite。 - 通配三类（域名、进程路径、进程名）仍须与配置其他处的 Clash 格式通配符区分；新仓库若改用另一套通配或把正则写入非
-REGEX类型，即属格式变化不合格。 NETWORK是否仍为tcp或udp；DSCP是否仍仅出现在其适用的 tproxy udp 语境说明下；IN-USER多个用户名是否仍用/分隔。
逻辑规则新写法必须仍是 LOGIC_TYPE,((payload1),(payload2)),出站，内层带类型。缺少括号或内层变成裸域名，视为格式被改坏。
审查 RULE-SET 名称与附加参数
RULE-SET,providername,proxy 中，集合名变化后需仍能对应已配置的 rule-providers，这是引用成立的条件。不能把新仓库的正文粘进这一行的第二段，也不能省略出站。附加参数只检查目标 IP 类：no-resolve 与 src 仅支持关于目标 IP 的规则；新仓库若把它们加到 DOMAIN、GEOSITE、PROCESS-NAME 或 RULE-SET 行上，应记为不兼容变化。src 会把目标 IP 匹配转为来源 IP 匹配，与来源类 SRC-* 规则不是同一写法，更换仓库时不要把二者当成可互换标记。MATCH 仍应无需条件，出现在列表底部时不要被新仓库改成带载荷的形式。
审查通不过时下一步
对不合格行，按本页示例改回同构字段：补类型、改载荷、保留出站、逻辑规则补括号。RULE-SET 名称对不上就只处理名称与 rule-providers 的对应，不要改成 DOMAIN 引用。目标 IP 附加参数位置错误则移到 IP-CIDR、IP-SUFFIX、IP-ASN、GEOIP 行末或删除。进程路径与进程名被对调时，改回各自类型。若大量行都无法映射到类型列表，停止合并，先抽出几条用文档总表示例对齐，确认格式基线后再逐类迁移。未完成格式对齐前，不要依赖列表顺序去「跳过」错误行——优先级只在格式可解析之后才有意义。