工作管理員裡 verge-mihomo 佔了六七百 MB？先說結論：150–300 MB 屬於正常範圍，長期超過 500 MB 才值得動手最佳化。下面五個設定按價效比排序。

調整設定後 Clash Verge 記憶體佔用從 480MB 降至 190MB 的曲線
最佳化設定生效後，記憶體曲線肉眼可見地掉下來

1. 關掉不用的日誌（收益最大）

日誌等級設為 debug 時，核心會在記憶體裡保留海量日誌緩衝。「設定」裡把日誌等級調回 info，排障時才臨時開 debug。如果你開過「日誌」頁面忘了關等級，這一項能省下上百 MB。

合作推薦 訂閱連結從哪來？ 本站合作機場註冊即送 1GB 香港高速體驗流量，可直接一鍵匯入。 取得高速節點

2. 控制連線數量

BT 下載、P2P 應用動輒幾千條併發連線，每條連線核心都要維護狀態。兩個做法：

  • 給下載工具加程序直連規則（PROCESS-NAME,qbittorrent.exe,DIRECT），P2P 流量不進核心；
  • 「連線」頁面看當前連線數，異常膨脹（上千條）時先找出發起程序。

3. 給訂閱瘦身

有的訂閱塞了五六百個節點、幾十個分組，配置物件全部駐留記憶體，測速時更是成倍放大。用 Script 過濾掉用不上的節點：

function main(config) {
  // 只保留港、日、新節點
  config.proxies = config.proxies.filter(
    p => /HK|JP|SG|香港|日本|新加坡/.test(p.name)
  );
  return config;
}

4. 放寬自動測速間隔

url-test 分組預設每 300 秒全量測速一次，節點多時是不小的週期性開銷。在 Merge 裡覆蓋分組參數，把 interval 放寬到 600–900 秒，順便加上 tolerance: 50（新舊節點延遲差 50ms 以內不切換），還能減少遊戲中的意外換節點。

5. 核心層的記憶體回收參數

Mihomo 支援更激進的垃圾回收，在 Merge 里加：

profile:
  store-selected: true
tcp-concurrent: true
keep-alive-interval: 15

另外，設定頁裡如果開啟了「記憶體回收」或類似實驗性選項（不同版本名稱略異），可以開啟觀察效果。

什麼時候該懷疑不是記憶體問題

  • 越用越大、重啟才降——先升級到最新版，歷史版本修過幾處記憶體洩漏；
  • 介面卡但記憶體正常——多半是「連線」頁面開著且連線數巨大，關掉該頁面即可；
  • 整機卡頓——檢查是否有其他程式在跟 Clash 搶 CPU（防毒即時掃描核心程序很常見，加白名單）。

最佳化完重啟一次軟體讓所有參數生效，再用工作管理員觀察半天的曲線，比盯瞬時值更能說明問題。