这类诉求在解决什么问题
很多用户的真实流程是：主线路来自机场或团队的 Clash 订阅，文件里已带好 proxy-groups、rules 甚至 rule-providers。你想额外挂一个备用订阅、自建节点，或给某几个域名单独指定策略，却不想把远程拉下来的大段内容手改到面目全非 —— 一旦点「更新订阅」，手改就丢了。把不随订阅更新而消失的片段抽出去，在合并层里解决，是「配置管理」里的一条主线；mixin 覆写正落在这一条上，与单讲 GEOIP、Sniffer 或 relay 语法的文章成互补，而不是重复。
另一个常见误会是：在编辑器里加了几行，却感觉「不生效」。除语法错误外，更要看最终送入内核的那份合并结果里，你的规则行排在哪、是否被更宽的规则或远程 RULE-SET 抢先。读完本文，你应能稳定回答两件事：我的 mixin 合进去了吗？ 以及 合进去以后，在整张 rules 里站在第几行？ 后一问请结合 规则顺序与 MATCH 写法 一起做。
mixin 是什么：不是第二份主配置，而是「增量层」
在 Mihomo 的配置里，mixin 通常指向一个本机存在的 YAML 文件路径（如 ./mixin.yaml，具体相对谁取决于启动目录与客户端约定）。启动或重载时，内核会把该文件与主配置做深合并：在映射（dict）型字段上一般按 key 归并，你的 mixin 可补新的 proxy-providers 条目、新的 proxy-groups 成员、或往 DNS 等段落加键。这样做的直接好处是：主订阅文件仍可原样从远端获取，你只维护小而清晰的 mixin，版本控制时 diff 也干净。
许多图形客户端在界面里提供「覆写 / Merge / Patch」之类入口，底层往往就是生成或引用这么一段合并逻辑；名称因壳而异，但心智模型可以统一成一句话：主包负责「默认长什么样」，覆写负责「我额外要什么」。与 Subconverter 侧「先生成、再进客户端」的流水线也能衔接：远端的格式先落地，mixin 只处理你本机要追加的那一层。
订阅合并、规则追加：先搞懂「列表型字段」
proxy-providers 这类以名字为 key 的字典在 mixin 里很顺手：你只要在 mixin 中再声明一个 provider 名称，不必碰主包里的 key，相当于旁路多挂一路订阅。合并多家订阅的常用姿势之一，就是让主配置保留原机场名，mixin 里加 sub-b、sub-work 等自定义 provider，再在 proxy-groups 里用 use 或显式 proxies 把新名字挂进你关心的策略组（若与主包同名的组需要并集节点，应在你使用的内核与客户端下核对「同组名是替换还是数组合并」——以实际导出/调试视图为准，勿想当然）。
rules 是有序列表，合并语义最容易踩坑：不同版本/客户端在「主配置与 mixin 都含有 rules 数组」时，是整表替换、前后拼接，还是由 GUI 再拆成「前插/后补」，表现并不总一致。工程上可操作的结论是：不要猜编辑器里那一份的肉眼顺序，要看客户端提供的「完整运行配置 / 调试用最终 YAML」里合并后的 rules 表。若你只有少量例外，可优先用 RULE-SET、rule-providers 把自定义规则成块引用，行序更透明；与「国家/站点桶」类总表配合时，可继续读 GEOIP 与 GEOSITE 分流。
# config.yaml (fragment) — main points to mixin
mixin: ./mixin.yaml
# mixin.yaml (fragment) — add another provider, group tweak, and rules
proxy-providers:
my-extra:
type: http
url: "https://example.com/extra-clash.txt"
path: ./p-my-extra.yaml
interval: 3600
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300
proxy-groups:
- name: PROXY
type: select
proxies: [DIRECT, my-extra, sub-main]
# rules: put personal exceptions; verify merged order in your GUI export
rules:
- DOMAIN-SUFFIX,internal.corp,REJECT
- DOMAIN-SUFFIX,example.com,DIRECT
上例中 PROXY 的写法仅为示意，真实组名、代理名须与主配置已有名称可解析；若主包中已有 PROXY 且合并行为是深合并而非整段覆盖，你更需要用面板验证最终的 proxies 列表。上面代码注释使用英文，便于直接粘贴到本地文件，避免混用多语言 key。
和 profile 不是一回事
profile 段在 Mihomo 里多用来描述运行期配置档案行为，例如是否记忆当前选中的节点、Fake-IP 缓存是否持久化等（常见键名以你所用版本文档为准）。它解决的是「这次关机之后要不要记住我选了哪条线」「缓存是否落盘」这类状态与持久化问题，而不是「把第二份订阅合并进配置」的语法层。若你搜索「profile」时想要的是多份 profile 槽位、切换不同主 YAML，那是壳与发行版的产品能力（多配置档、多工作区），与内核的 profile: ... 键在手册里的含义要分语境读。记住：mixin 管结构合并；内嵌 profile 管档案行为；GUI 的「配置档」管你正在用哪份主文件，三者不互相替代。
落地步骤：可复查的检查点
- 主订阅照常填：远程 URL 或壳内订阅管理不折腾。
- 新建 mixin 文件，只放增量：providers、要挂进组的节点名、以及你负责的规则或 rule-providers。
- 在主配置根级写好
mixin: <path>，或按客户端在设置里打开「mixin/覆写」并指向该路径。 - 重载后导出完整配置，在
proxy-providers与rules中确认多路订阅是否都在、规则行序是否符合预期。 - 若节点名变化（订阅更新导致），策略组与规则里引用的名字要同步，这与是否使用 mixin 无关，属于配置一致性话题。
在 Docker 或 Linux 上跑 Mihomo 时
容器与 systemd 场景下，mixin 路径常写成卷内相对路径，与 Docker 卷与端口映射、Linux TUN 常驻 一起看：主配置与 mixin.yaml 都应在挂载卷上可写可读，重载时避免工作目录与镜像内相对路径对不齐。外控 external-controller 若已按 Yacd 面板文 配好，用「查看当前配置」类接口能更快验合并结果。
提示：同一主配置若既在 GUI「规则最前/最后插入」里填了一段，又手写 mixin，再叠远程 huge RULE-SET，最终行序只以合并输出为准。改不动时，先对连接日志，再对「导出的 rules 全文」。
关于获取客户端：需要安装包与图形界面上手时，请优先 本站下载页；开源仓库宜用于查 Issue 与行为变更，与「点哪下载 EXE/APP」分开理解。
合规提醒：请仅在法律与网络使用政策允许的前提下使用代理与第三方节点；企业或校园网请先遵守当地规范。
小结
Mihomo 的 mixin 覆写，核心价值是把个人增量从会频繁刷新的主订阅里剥离：多家 proxy-providers、补节点/补策略组、以及自维护 RULE 或规则集，都可放到独立 YAML 再合并。它与 profile 键所侧重的运行期档案/持久化、以及各 GUI 的「多配置档」不混为一谈。真正决定流量走向的仍是合并后规则表的全序；与 站内配置总览、规则顺序文 连读，就凑齐了「多份配置怎么组织」与「同一表里谁先匹配」这对进阶搭档。
若你更偏向开箱即用的 Clash 客户端、在界面里完成订阅与简单覆写，而少手写路径，Clash 系在可观测性与规则可合并性上仍对长期维护很友好。相比在一份远程大文件上反复打补丁，用 mixin 把个人片段源控住，主订阅只负责随服务商更新，迭代成本通常更低。