覆写解决的是订阅更新后自定义丢失

官方文档已使用 Clash Party 名称，而一些旧版文档、文件名或搜索词仍会写 Mihomo Party。本文中两个名称指向这个客户端的前后品牌表达，不代表需要安装两个程序。使用时仍应从当前官方仓库和文档确认界面与版本。

官方覆写指南将用途定义为对订阅配置做自定义修改，并让这些修改在订阅更新后仍然生效。覆写文件只写你想改的键，客户端在加载时将它与订阅的原配置合并。这比每次直接修改下载后的主 YAML 更容易追踪，也更容易撤回。

覆写不是订阅转换。它不会创造节点，也不会修复已过期的 URL。应先确认原订阅可下载、可解析，然后才用覆写调整规则、DNS 或代理组。

先选全局或指定订阅，再导入并绑定

Clash Party 的覆写可以全局启用，也可以只指定到某个订阅。对初次使用者，更安全的做法是先绑定一个测试订阅：只有这份配置受影响，其他已知可用的订阅可作为对照。只有当同一项改动确实适用于所有配置时，才考虑全局开启。

  1. 在左侧导航打开「覆写」，从本地文件导入一份自己可审查的 YAML，或使用可信的直接链接导入。
  2. 点击刚导入的覆写，只保留本次需要的字段，保存后记下其名称。
  3. 进入「订阅管理」，打开目标订阅右上角三点菜单，选择「编辑信息」。
  4. 在对话框的「覆写」项选中这份 YAML，保存后重新加载目标订阅。
  5. 打开最终生效配置或日志，验证修改的键真正进入内核，而不是只看覆写编辑器显示“已保存”。

从 URL 导入覆写时，对方未来可以改变内容。对 DNS、脚本、远程规则集或外部控制器的修改，建议先保存本地副本并逐行审查。不要把包含私有 Token 的订阅主文件误当覆写公开分享。

理解标量、对象与数组的合并规则

官方 YAML 文档说明，覆写采用深度合并，但优先级低于应用的常用配置覆写。简单值会直接替换；嵌套对象会递归合并；在键名后加 ! 可强制替换整个对象。数组不应想当然地当作追加：默认写法会替换，使用键名前或后的 + 才表示前置或追加。

# 将自定义规则放到原规则之前
+rules:
  - DOMAIN,example.internal,DIRECT

# 将一条规则追加到原规则之后
rules+:
  - DOMAIN-SUFFIX,example.net,Proxy

上面的 example.internal、example.net 和 Proxy 都是占位符。你必须把策略名替换为当前订阅中真实存在的代理组；否则 YAML 语法可能完全正确，内核却会因目标策略不存在而拒绝加载。

规则是按顺序匹配的。前置一条宽泛规则可能截获原订阅本应更精确匹配的流量；追加在 MATCH 之后的规则则可能永远不会到达。保存前要同时看内容和位置。

先用一条可观察改动测试，再更新订阅

首次测试不要同时覆写 DNS、TUN、代理组和几十条规则。选择一个可观察、可撤回的字段，例如一条只针对自己控制的测试域名的前置规则。保存后重新加载订阅，在连接或日志中确认该域名命中预期策略，其他流量保持不变。

  1. 记录覆写前的订阅名称、覆写绑定和测试请求的实际策略。
  2. 启用只有一项改动的 YAML，重新加载并重复同一请求。
  3. 确认命中发生预期变化后，手动更新订阅，不编辑下载后的主配置。
  4. 更新完成后再做一次同样测试，确认覆写仍被绑定并参与合并。
  5. 最后禁用覆写并重新加载，确认原行为能恢复，证明回退路径有效。

“编辑器保存成功”、“订阅更新成功”和“内核已加载最终配置”是三个不同检查点。覆写的价值正是更新后继续应用，因此没有完成“更新后再验证”，就还不能说这份覆写可靠。

解析失败或规则异常时先解除绑定

覆写之后无法加载配置，最快的恢复方式是在「订阅管理 → 编辑信息」中先解除该覆写，然后重新加载原订阅。不要一开始就删除订阅、覆写和应用数据；解绑足以判断错误是否来自合并结果，而且保留了待审查的 YAML。

YAML 覆写异常快速定位
现象优先检查恢复动作
保存时语法错误缩进、冒号、数组符号和引号恢复到最小的单键覆写
内核提示策略不存在规则末尾名称是否与订阅代理组完全一致改用已存在的策略名
原规则整段消失是否把 rules: 写成数组替换按需要改用 +rules: 或 rules+:
修改完全没有生效覆写是否绑定到当前订阅，是否被更高优先级设置覆盖核对绑定与最终生效配置

将覆写作为一份可版本化的小型补丁：文件名写清用途，注释记录它假定存在的策略组，每次只加一类改动。订阅服务商一旦改名代理组或改变规则结构，可以快速看出哪条假设已经过期，而不是把所有问题统称为“覆写坏了”。

官方来源与版本边界

版本号、文件名和界面文字可能随项目更新而变化，操作前请以链接中的项目文档为准。