1. 语法语义边界精准辨析表
通过以下实测样例，清晰掌握三者的命中差异：
| 规则指令 | 规则内容 | 目标请求: `google.com` | 目标请求: `www.google.com` | 目标请求: `google.cn` | 目标请求: `notgoogle.com` |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **DOMAIN** | `DOMAIN,google.com` | ✅ **命中** | ❌ 未命中 | ❌ 未命中 | ❌ 未命中 |
| **DOMAIN-SUFFIX** | `DOMAIN-SUFFIX,google.com` | ✅ **命中** | ✅ **命中** | ❌ 未命中 | ❌ 未命中 |
| **DOMAIN-KEYWORD**| `DOMAIN-KEYWORD,google` | ✅ **命中** | ✅ **命中** | ✅ **命中** | ✅ **命中（误伤）** |
💡 绝大多数情况下，日常分流规则都应该采用 `DOMAIN-SUFFIX`。
2. DOMAIN-KEYWORD 的严重误伤隐患
很多初学者图省事，喜欢写：`DOMAIN-KEYWORD,apple,PROXY`，以为这样就能把苹果公司的服务全部分流进代理。
### 带来的严重连带误伤：
- 国内存在大量带有「apple」字母的合规网站（如某家卖苹果水果的水果电商网 `apple-farm.cn`、某家科技博客 `appleinsider.com.cn`）；
- 这些网站本来应当在本地直连秒开，但因为域名中包含了 `apple` 子串，**全部被强制送入了海外代理**！
- **法则**：只在针对特定恶意广告或违规追踪库进行全盘封杀时，才推荐使用 DOMAIN-KEYWORD（如 `DOMAIN-KEYWORD,adservice,REJECT`）。
yaml
# 正确的分流写法范例
# 严禁写: DOMAIN-KEYWORD,github,PROXY
# 正确规范写法:
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,githubusercontent.com,PROXY
- DOMAIN-SUFFIX,github.io,PROXY3. 底层数据结构与基数树（Radix Tree）性能实现
Mihomo 针对 `DOMAIN-SUFFIX` 做了极致的算法优化：
- 内核在启动时，将所有后缀规则构建为一棵 **倒排基数树（Reverse Radix Tree）**；
- 匹配 `news.google.com` 时，算法从根节点出发，先匹配 `com`，再匹配 `google`；
- 时间复杂度仅与域名的层级深度（通常为 2~4 层）相关，与规则库内包含 10 条还是 10 万条规则完全无关！
- 因此，放心地使用数万条 DOMAIN-SUFFIX 规则集，性能损耗完全可以忽略不计。
❓ 常见疑问与排查步骤
DOMAIN-SUFFIX,com,DIRECT 这种规则能写吗？
绝对禁止。这是粗暴的顶级域匹配，会导致全球所有以 .com 结尾的网站全部被直连捕获，海外网站直接瘫痪。
区分大小写吗？
不区分。Mihomo 内核在匹配前会自动将数据包中的域名统一转换为标准小写字符后再执行检索。
支持通配符 * 吗？比如 *.google.com？
Clash 标准规则中不支持在 DOMAIN 规则里手写 * 通配符。通配整个子域名的标准做法就是直接使用 `DOMAIN-SUFFIX,google.com`。