为什么手动加在配置里的规则在点完更新后离奇消失？本文深入解析客户端配置文件生命周期，指导用户利用正规的覆写（Override）模块实现配置的高效持久化。
对于许多进阶用户来说，从随便云服务中心拉取到基础订阅后，往往希望在本地补充几条自己的私有分流规则，或者调整某些策略组的显示顺序。但令人沮丧的是，一旦在客户端中点击了“更新订阅”，之前花时间精心修改的内容瞬间被抹得一干二净。要解决这个问题，必须搞清楚客户端内部的“配置生命周期”与“覆写机制”。
首先必须明确：客户端中的“订阅配置”本质上是一份由远端服务器托管的“只读镜像”。当你在客户端中点击更新时，客户端所做的事情是向服务端发起一次标准的 HTTP GET 请求，将服务器返回的全新 YAML 文本完整写入到本地的存储文件中。在全量覆写的逻辑下，本地文件上曾经发生过的任何直接字符改动，都会被服务端的最新版本无条件覆盖。这是为了确保当服务中心调整了服务器节点地址或升级了加密协议时，用户端能及时无缝同步。
那么，怎样才能既享受自动更新节点的便利，又能保留自己的个性化配置呢？现代成熟的 Clash 衍生客户端（如 Clash Verge Rev、Mihomo Party 等）引入了“分层覆写”（Override / Mixin）机制。
在覆写架构中，整个系统的运转流程被清晰地划分为三个层级：
第一层是“原始输入源”（Remote Source），即从随便云定期拉取的只读基础文件；
第二层是“本地覆写层”（Local Overwrite），这是独立存储于另一个受保护文件中的用户自定义修改脚本或增量 YAML 补丁；
第三层是“运行态配置”（Runtime Config），这是客户端每次启动内核前，在内存中将输入源与本地覆写层即时合并（Merge）后生成的最终配置文件。
理解了这个生命周期，就能明白：我们永远不应该直接编辑从远端下载回来的原始文件，而应当将自定义需求写在独立的“覆写规则”中。
为了帮助大家掌握标准的覆写写法，下方展示了典型的配置合并层次：
| 层次定位 | 存储位置与属性 | 是否受订阅更新影响 | 建议承载的内容 |
|---|---|---|---|
| 远程订阅源 | profiles 目录下的下载缓存（只读） | 每次点击更新都会被全量重写 | 官方节点集合、基础公共策略组 |
| 本地覆写补丁 | 独立的 overrides / mixin 文件 | 永久保存在本地，绝不受更新影响 | 私有域名分流、自定义策略组、DNS微调 |
| 内存运行时 | 临时生成的 config.yaml（内核读取） | 每次内核重启或订阅拉取后重新生成 | 合并后的完整最终生效配置 |
在 Clash Verge Rev 等主流客户端中，推荐通过“扩展配置（Script / Merge）”来实现规则持久化。例如通过 YAML 字典合并语法，将自定义的 prepend-rules（前置规则）注入到配置中：
通过在覆写模块中声明前置规则，系统在合成最终运行时配置时，会自动将你的私有规则插入到所有规则的最顶端。这样一来，无论随后的远端订阅如何更新节点列表，你的私有分流规则都会稳居首位优先匹配。
牢记这一核心原则：让订阅源专心管理节点，让本地覆写专注管理规则。两者各司其职，从此告别每次更新订阅后重复手工修补配置的烦恼。