一、Mixin／patch 解决什么问题
许多用户的日常流程是：在图形客户端里粘贴订阅链接，由软件拉取远端已经拼装好的大型 YAML。这份文件里往往已经含好 proxies、proxy-groups、一条很长的 rules 以及可能很长的 rule-providers。当你只想改其中一小点——比如内网 IP 必须先 DIRECT、公司域走后门、或把 dns.nameserver-policy 再细分一段——若每次都手工下载订阅全文再本地维护，很快就会在合并冲突与更新覆盖里崩溃。
Mixin 与 patch（各客户端可能叫「扩展配置」「覆写」「Override」）提供的是同一类思路：让订阅基线保持只读或可重复生成，把个人差分放在另一层。Clash Meta／Mihomo 内核最终只吃一份展开后的配置；差分层由客户端或外层工具在载入前拼好。你要搞清楚的是：这一层是字典级深合并，还是对列表做 prepend／append，以及这条链路在「远端订阅」之前还是之后执行——这直接决定你写的键有没有出现在最终文件里。
若你已经在用远程规则集但仍搞不懂「列表接入点」，可先读 rule-providers 与 RULE-SET 专文；它讲外部规则文件与 interval，本文讲在不重建整表 rules 的前提下如何插队与覆盖字段。
二、三种能力对照：深合并与插队
社区口语里「Mixin」「patch」「profile override」常被混用，落地到你屏幕上的菜单时却可能是三个入口。可以按对 YAML 的作用方式来记，而不是按英文名硬背。
| 能力类型 | 典型行为与适用场景 |
|---|---|
| Mixin（深合并） | 把补丁文件里的映射嵌进已有结构：同名键在更「外层」或更「后执行」的一側胜。适合改 dns.enable、补充 tun、追加监听端口旁的小块，而不是把八百行 rules 重写一遍。 |
| patch（列表插队） | 使用 prepend-rules、append-rules（或客户端暴露的等价字段）在不替换整段 rules 的前提下插入若干行。适合「几条公司域名必须走某某策略组」这类点对点的优先级调整。 |
| 脚本覆写 | 少数客户端支持在载入前跑脚本，对整个对象树做程序化改写；能力强，但排错困难。只有在菜单化覆写不够用时再考虑。 |
深合并并不自动帮你处理「整条 rules 数组谁在前」这种顺序语义：YAML 里列表的顺序就是内核匹配顺序，合并两个大列表时若实现简单拼接错误，仍会得到难查的命中结果。因此要插队时，优先找显式的 prepend-rules／append-rules，而不是臆测「我的 Mixin 文件写在后面所以整段 rules 都排在后面」。
三、配置合并链：谁先谁后
通用原则
可以把合并想象成多层透明胶片叠在一起：每一层要么改某个键的值，要么在 rules 队伍里加塞几个人。谁在物理上更晚执行，谁就更容易在「同一键名争一个座位」时赢；但 rules 队伍有时不是整表替换，而是 prepend 永远插在队首、append 插在队尾——于是「谁晚执行」和「插队长短」要分开想。
不同发行版菜单名字差异很大：有的把「全局扩展」放在订阅之前，有的把「单订阅覆写」放在最后。这里没有放之四海皆准的一张表能替代你手头软件的说明书。实操时记住一句：以预览里的最终 YAML 为准，而不是以你心里以为的保存顺序为准。
与「订阅更新」之间的关系
订阅每次刷新，基线文件可能整体替换。若你的个人片段是挂在「订阅外部的 Mixin」，一般不会被覆盖；若你直接改了订阅缓存里的正文，下次更新又会丢。长期可维护的做法是：基线只读、差分外挂。这也是 profile override 作为功能存在的核心原因。
external-controller、mixed-port 等与界面绑定的字段，你在 Mixin 里改了也可能被 GUI 再盖回去。若遇此情况，以界面可调项为准，或查阅该字段是否标记为不可覆写。
四、patch 路径与 YAML 写法要点
下面是「说明性」片段，字段名需与你所用客户端／内核版本对照，不要原封不动复制生产环境密钥或订阅地址。
# Illustrative patch/Mixin fragment — adjust keys to your client.
# prepend-rules execute first in the final rules list (highest match priority).
prepend-rules:
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- DOMAIN-SUFFIX,corp.example,PROXY-OFFICE
# Optional tail rules; useless if placed after a final MATCH in the merged list.
append-rules:
- DOMAIN-SUFFIX,lab.example,DIRECT
# Deep-merge style snippet (Mixin): overlay dns fields without retyping full rules.
dns:
enable: true
nameserver-policy:
"+.corp.example": "223.5.5.5"要点拆解：
prepend-rules：合并完成后一般出现在最终 rules 的靠前位置，因此适合「必须早匹配」的内网段、办公域名、或你要强制纠正订阅里过宽 DOMAIN-SUFFIX 的例外。append-rules：逻辑上插在队尾；若合并后的列表在更前面已有MATCH兜尽所有连接，append 的行可能永远轮不到。- Mixin 风格的
dns:块：常用来做字段级补足；若基线已有完整dns，合并时要特别留意是否会意外覆盖整个子树，仍应以预览为准。
站点总文档中的规则写法示例见 配置文档 对应章节；把那里的 DOMAIN-SUFFIX 等行搬进 prepend-rules，本质上与写进主 rules 数组无异，只是插入点由配置合并代劳。
五、规则链表：prepend 与 MATCH
Mihomo／Meta 对 rules 的语义仍然是自上而下第一条命中即停。这与你在覆写里用的是「整表替换」还是「prepend 插队」无关——最终得到的仍是一张大表。于是：
- 订阅原文若在中间就写了极宽的
GEOIP,CN,DIRECT，而你的例外域名排在它后面，除非你用prepend-rules把它顶到更前，否则命中顺序对你不利。 MATCH若出现，而且后面没有再多一行，那么所有 append 在 MATCH 之后的规则都失去意义。- 与 url-test、负载均衡策略组配合时，改的是出站选路；覆写改的是先进哪个策略组。延迟优化参见 url-test 与健康检查。
排查时建议开一个测试域名，在连接日志里看「命中哪一行」。若显示的行号位于订阅大段之中，而你的 prepend 明明写了更具体的 DOMAIN，却仍未命中，就要回头检查：prepend 是否真的进了最终文件、是否拼写或策略组名不一致导致加载失败退回旧配置。
六、与 rule-providers、DNS 的关系
rule-providers解决的是「成千上万条第三方列表放哪、如何更新」：RULE-SET 只是在 rules 表里占一行或几行占位符，大规模内容在外部文件。你可以在 prepend 里先写几条裸 DOMAIN，再在订阅里接 RULE-SET，顺序同样遵守自上向下。
DNS 与覆写经常一起出现，是因为订阅模板未必照顾你本地解析习惯。把 nameserver-policy 或 fallback-filter 放进 Mixin，通常比手改订阅安全。系统性的 DNS 链路解释见 nameserver 与 fallback 分步设置；改完 DNS 后若分流仍怪，先确认 fake-ip 与规则的交互是否在别处文档已讨论。
七、常见坑与验收方法
键名与策略组引用
覆写里若新增 LOCAL-MAIL 策略组并在 prepend 中引用它，必须保证合并后的 proxy-groups 真包含该名。常见错误是 Mixin 写在订阅之前执行，订阅正文后来定义同名组把它形状改掉，或引用名错别字导致整份配置校验失败，客户端静默回滚到上一份可用配置，让你误以为「prepend 没生效」。
与 PROCESS-NAME、TUN 的交叉
覆写只改配置文件；进程级规则还要满足 TUN／find-process 等运行条件。进程路径类问题与本篇正交，可按 Windows PROCESS-NAME 排查单独处理。
验收清单
- 保存后在客户端执行「重载」或「重新生成运行时配置」。
- 在预览里全文搜索你的特征域名或
# comment tag。 - 发起到该域的连接，核对日志命中行与策略组。
- 若失败，优先看内核日志的配置解析错误，而不是先怀疑节点质量。
八、常见问题
Mixin 和 patch 有什么本质区别？
Mixin 偏向对象字段级的深度合并；patch 常以 prepend-rules／append-rules 形式显式操纵列表顺序。不确定时用预览的最终 rules 为准。
为什么 append-rules 有时完全不生效？
因为 MATCH 或等价兜底若已吃光所有连接，末尾追加的行不会再被评估。需要 late exceptions 时，反而要想是否应改用更靠前的 specific 规则或调整订阅结构。
配置合并的先后顺序由谁决定？
由你使用的客户端与其版本实现决定。阅读官方文档中「配置生成顺序」「Profile Merge」章节，并以运行时预览为最高权威。
覆写和 rule-providers 应该先用哪个？
大块规则集走 rule-providers；少量插队、DNS 小改走 Mixin／prepend。组合使用非常普遍。
九、小结
在 Clash Meta／Mihomo 生态里，Mixin、patch 与各种 profile override 菜单，本质都是把「订阅基线」与「个人差分」拆开：深合并改结构化字段，prepend／append操纵 rules 顺序。真正决定体验的是两层东西：合并链谁先谁后，以及最终 rules 表里谁先被匹配。把这两点核对清楚，你就不用在每次订阅更新后重写几百行 YAML。
市面上也有只靠单份巨型配置文件、或只靠远程面板改节点、却难以下沉到「规则插队／DNS 细分」层面的工具：更新倒是省事，一旦遇到企业内部域、实验室网段、或国内外解析分叉这类长尾需求，往往只能整体换模板。Clash 系把配置拆成可合并的层次后，配合 rule-providers 与本地覆写，能在不大改主 profile 的前提下做精调；这也是 Meta／Mihomo 用户愿意维护一份可读 YAML 的原因。
若你希望用跨平台一致、规则与覆写能力完备的客户端承载这些片段，可从本站安装包起步，把订阅与 Mixin 分开维护，再用本文的验收步骤核对「预览—日志」闭环。