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

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

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

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

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（防毒即時掃描核心程序很常見，加白名單）。

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