為什麼要覆寫，而不是直接改訂閱下載下來的 YAML？
多數使用者取得的是帶有完整 proxies、proxy-groups 與 rules 的遠端設定；只要客戶端觸發更新，就會以伺服器回傳內容重寫檔案。您若在該份檔上直接加節點、改 DOMAIN-SUFFIX 或重排 rules，一次更新就會讓變更蒸發。合理的分工是：訂閱只負責「帶上機場的節點與策略骨架」，而個人化（公司內網、額外機場、自架節點、以及您堅持要墊在清單前段的規則）放在另一層，由核心在啟動或重新載入時做深度合併。
在中文社群常把這個二階層稱作 mixin 或 覆寫；圖形介面則多叫「Merge 設定」或擴充檔。名稱不必糾結，要緊的是：您寫的覆寫檔是附加語意，底層欄位未重複時會保留遠端內容，列表型欄位則依 prepend-／append- 或客戶端實作插入到最終清單的前段或尾段。這和「學一條新的規則語法」是不同層次——前者管多份檔案如何併成一份執行中設定，後者管命中後導去誰。兩層都對，讀者才不會在論壇上把「合併沒套到」和「策略組名寫錯」混在一起。
覆寫檔常見欄位：prepend-* 與 append-*
以 Clash Verge 系列文件所描述、且與 Meta 語法手冊可對讀的 Merge 寫法為例，同一份覆寫可以同時攜帶多種「清單型」欄位的前置與尾置版本，例如 prepend-rules、append-rules、prepend-proxies、append-proxies、prepend-proxy-groups 以及各種 proxy-providers／rule-providers 的對應變體。它的設計出發點很直白：讓訂閱產生的大型清單維持在「中腹」，讓使用者在不碰遠端原文的前提下，用本地一小段補上例外。
重點：在 規則由上而下、先命中先停 的前提下，多數可讀的「自訂分流」應寫在 prepend-rules，讓它們有機會排在訂閱內大段 GEOIP／MATCH 之前。若用 append-rules 把行加在遠端 MATCH 之後，新行往往永遠輪不到，因為每筆流量早已由前面的 MATCH 收走。
實務上可記一句口訣：要蓋在別人前面，用 prepend；要接在清單尾巴做微調，才考慮 append，而且後者對 rules 幾乎永遠不是您想要的分流行為。若您是要補兩條內部網段直連、或幾條 DOMAIN 去固定策略組，放在 prepend-rules 通常最符合直覺；尾端大段 MATCH 的語意，請參考本站 規則順序專文 一節的說明。
# Snippet — merge / mixin overlay; names must exist in final merged config
prepend-rules:
- DOMAIN,corp.intra.example,DIRECT
- DOMAIN-SUFFIX,dev.example,PROXY
append-rules: []多家訂閱合併：用 proxy-providers 疊在骨架上
「訂閱合併」有兩種常見讀法：第一種是節點層併寬——A 機場與 B 機場的節點同時出現在同一個執行中設定；第二種是只合規則不增加出口。若您的目標是前者，在 Mihomo 路線上多會改以多個 proxy-providers 指向不同 url 或本機檔案，讓 proxy-groups 的 use 把多邊匯入同一個策略組；遠端訂閱若已自帶一份完整 proxies，也仍可額外掛一個 provider 專管第二家。重點是名稱唯一：重名節點在合併階段會變成難以預測的覆寫，建議實務上幫第二家加前綴，例如 JP2- 之類的辨識字。
純以覆寫檔寫 prepend-proxies 也可以塞入一兩顆自架節點；和 proxy-providers 相比，小量靜態節點用列表較好讀，大量訂閱則寧可用 provider 做快取與週期更新。兩者可以並存：底稿是機場下發，覆寫只補您真正擁有所有權的幾行。關於訂閱從 V2 原文轉成 Clash 形，另可參考本站 Subconverter 與格式轉換 的說明，但本文焦點仍放在合併層的寫在何處、何時生效，而非轉碼參數。
釐清：profile 不是「再疊一層訂閱或規則」
在 Mihomo 範本與多數社群文件裡，profile: 區段主要是行為參數，例如 store-selected 是否在重啟後仍記得您在介面上點的 select 策略。它處理的是「選擇狀態要寫入哪個目錄、存檔檔名與間隔」這類持久化，而不是另一份 YAML 合併語法。常見混同是把「profile 資料夾裡的 runtime 狀態」和「Merge 覆寫檔的靜態補丁」攪在一起：前者是執行時選了哪個節點，後者是您希望不論重載幾次都應該在的那份規則與自訂節點。
讀到這裡若仍覺得抽象，可記：profile ＝ 記帳本（哪些選擇要跨重啟保留）；覆寫／Merge ＝ 在底稿上貼的附註。兩邊不互斥，但解決的問題不同；搜尋「profile 訂閱合併」卻導到本文時，正確的期望是核對 store-selected 是否開了、歷程檔有沒有寫入權限，而不是在 profile 底下另寫一坨 rules 期待一定會合併——那是覆寫層或自訂主檔的職責。
圖形客戶端：多張 Merge 的啟用順序與重載
多數圖形殼在啟用多份 Merge 時，會依啟用順序依次套用；更動後常需停用再啟用或觸發一次重新載入，讓變更反映到產生的最終 config.yaml。實作面細節依版本而異，但排查思路相通：在介面產生器或產出檔裡，直接搜尋 prepend-rules 是否真的出現、是否夾在帶有 MATCH 的大表之前。若產生檔內沒有您的行，代表合併邏輯沒有跑到，而不是核心突然忽略規則。
另有一類讀者會在覆寫裡改 mixed-port、external-controller 或 log-level，卻察覺「怎麼都改不動」。圖形客戶端往往自己掌控這些關乎進程行為的欄位，避免與內部埠管理打架；實務上應在應用程式提供的設定畫面調，剩下留給覆寫去處理的，多半是分流與供應商清單本身。
合併後驗收：以日誌確認「實際載入的規則長相」
寫好覆寫卻不生效時，最省時間的做法不是重打訂閱，而是觀察產生後的完整 rules 陣列：先數條目次序，再開 log-level: info 讀一條目標流量，看第一條命中的規則列是否就是您在 prepend-rules 加的那幾行。與 connection reset 日誌專文 的套路一致，差別只是這次您要驗收的是合併邏輯有沒有把附註帶上來。
小結：合併後的「最終一條 rules」；prepend-rules 的相對前段；profile 的持久化分岔——三件事分開，就不會在論壇上把關鍵字搜混。
和本站其他主題的接點
本稿刻意與專教 GEOIP／Sniffer 語法的文章分線：那裡談的是單一檔內的規則行寫法，這裡談的是多份輸入如何併成單一執行中設定。兩邊在真實世界會交織——因為併完之後的順序，才決定您新加的那行 DOMAIN 有沒有機會出場。讀者若已讀完本文，建議以「底稿＋覆寫」的維護方式固定您的結構，再回頭到 relay 雙跳 或 TUN 相關長文補上場景化調校。
說明文件與安裝包
Mihomo 上遊以開源形態持續演進，語法以官方 Wiki 與專案內 config 範例為準。若需安裝圖形客戶端，建議優先使用 本站 Clash 下載頁，並搭配 設定與導讀；需要核對行為與提報問題時，再到公開程式庫查閱。將「可點即用的安裝路徑」和「讀源碼證實行為」分開，能少踩一類版本誤配。
提醒：代理與路由相關設定須符合所在地法規與服務條款；本文僅供合規的網路除錯與自用學習參考。
結語
Mihomo／Clash Meta 的進階用法，從寫幾行規則再往上長一層，就是學會不改底稿、只加覆寫：讓遠端訂閱照樣能更新，讓自訂節點與個人化規則有固定落點。掌握 prepend-rules 相對 append-rules 的實務差異、釐清 profile 與多檔合併的分工、並用日誌驗收合併後的最終清單，您就能把「多機場＋多例外」的複雜度壓在可維護的邊界內。相較於在單一靜態檔內打轉不更新訂閱，善用覆寫層通常能同時顧到可更新性與可預測的命中行為。
在體驗上，Clash 系圖形客戶端普遍把合併前後的產生檔與日誌對讀都做得比輸出一坨不明 YAML 的工具有辨識度；當合併邏輯內化後，您要動的只有覆寫小檔，而不再是整份下載內容。