本文目錄
先確認記憶體上漲是不是由日誌頁觸發
本文處理的是一個邊界很清楚的問題：Clash Party 啟動後原本穩定，開啟一次「日誌」頁面，再切換到其他頁面，應用記憶體仍持續增加。官方 issue #1976 已收到 Windows、macOS 與 Linux 使用者的相似意見回饋，涉及 1.9.6 和 2.0.0。
單純看到 Clash Party 佔用較高，並不能直接套用本文。訂閱更新、連線數量、規則集、TUN 和 Mihomo 核心都可能影響記憶體；只有「沒有開啟日誌頁時相對穩定，開啟後趨勢明顯改變」這一組前後對照，才接近目前已知問題。
先把四種現象分開
| 觀察到的現象 | 更可能的範圍 | 下一步 |
|---|---|---|
| 啟動後不開啟日誌頁，記憶體基本穩定 | 尚未觸發日誌頁問題 | 記錄基線，再做一次受控對照 |
| 開啟日誌頁後持續上漲，離開頁面也不停 | 與官方 issue 的觸發方式一致 | 完整退出後重新測試，並暫時避開日誌頁 |
| 從啟動開始就上漲，是否開啟日誌頁都一樣 | 可能是連線、快取、規則或核心的另一條路徑 | 分別觀察桌面應用與 Mihomo 處理程式，不直接歸因於日誌頁 |
| 只有 Mihomo 核心處理程式上漲，介面處理程式穩定 | 問題可能在流量、規則或核心 | 保留核心版本與執行設定，轉向核心側檢查 |
用十分鐘對照區分介面與 Mihomo 核心
測試前固定同一份設定、節點、網路和代理模式，不要一邊換規則一邊觀察記憶體。Windows 可用任務管理器，macOS 可用活動監視器，Linux 可用系統監視器；重點是分別記錄 Clash Party 應用處理程式組和 Mihomo 核心，而不是只看整機已用記憶體。
不需要一直盯著日誌內容，也不需要製造大量連線。用一個平時能穩定存取的網頁維持普通使用，就足以比較「從未進入日誌頁」和「進入後再離開」兩段趨勢。
完成一次可重複的前後對照
完整退出後重新啟動
從系統匣選單退出 Clash Party，確認應用及其子處理程式已經結束，再重新開啟；先不要進入日誌頁。
記錄五分鐘基線
在相同網路活動下，每分鐘記錄一次應用處理程式組和 Mihomo 核心的記憶體，避免用單個瞬時數值下結論。
開啟日誌頁一次
停留約一分鐘，讓頁面收到實時日誌；隨後切到首頁或代理頁，不要清空日誌、換設定或重啟核心。
再觀察五分鐘
繼續記錄同一組處理程式。若離開日誌頁後應用側仍連續上漲，而核心趨勢沒有同步變化，證據更接近已知問題。
兩段趨勢相近，而且都沒有持續上漲
目前沒有復現，不需要為這個 issue 更換版本或改設定。
日誌頁開啟後應用側斜率明顯改變，離開後仍上漲
進入下一節，用完整重啟暫時止損。
Mihomo 核心單獨上漲
記錄核心版本、規則模式和連線數量，停止把問題歸到桌面日誌頁。
開啟日誌頁時短暫增加，離開後很快穩定
這可能只是頁面正常載入；延長觀察，但不要把短時峰值當成洩漏。
已經觸發時，完整退出並暫時避開日誌頁
在穩定版收錄修復前，影響最小的規避方式是完整退出 Clash Party，再重新啟動並暫時不開啟日誌頁。官方 issue 中有使用者意見回饋，重啟應用可以把已經增長的記憶體恢復到正常起點；這只是解除目前會話中的殘留日誌流，不代表程式碼問題已經修復。
直接關閉主視窗可能只把應用收進系統匣。應使用系統匣選單中的退出操作，並在系統監視工具裡確認 Clash Party 及相關介面處理程式已經結束。若系統代理或 TUN 沒有自動恢復，先按原設定關閉它們，確認直連正常後再啟動用戶端。
先恢復一個可長期使用的狀態
記下目前設定
記錄目前 Profile、代理模式、系統代理和 TUN 狀態，不刪除訂閱或覆寫。
從系統匣完整退出
等待應用處理程式結束；若仍有介面處理程式停留，先等待正常退出，不隨機結束 Mihomo 之外的系統處理程式。
重新啟動並恢復代理
使用原設定存取同一測試網頁，確認節點、規則和連線仍正常。
保持日誌頁關閉
在首頁、代理頁和連線頁完成日常操作，再觀察十分鐘，確認記憶體不再沿原趨勢增加。
為什麼離開日誌頁後，資料流還可能繼續存在
Clash Party 的日誌頁不是一次性讀取文字，而是從主處理程式建立實時日誌連線，再把事件送到介面。官方修復提交 5532a851 的目標很明確：頁面卸載時移除介面監聽，同時停止主處理程式的日誌 WebSocket。
這也解釋了為什麼單純切到其他頁面未必立刻停止增長：舊行為下，畫面雖然消失，實時日誌鏈路仍可能繼續接收資料。這個結論只解釋與日誌頁觸發一致的情況，不能替代對 Mihomo 核心、連線快取或其他頁面的獨立診斷。
- Mihomo 核心持續產生執行日誌
- 主處理程式日誌連線透過 WebSocket 接收實時日誌
- 介面監聽器把日誌事件傳送給渲染頁面
- 日誌頁顯示、篩選並保留目前日誌
已合入原始碼的修復會在離開日誌頁時同時停止介面監聽和主處理程式日誌連線，避免頁面卸載後資料流繼續存在。
v2.0.1 已收錄日誌流修復，升級後仍要重新測試
截至 2026 年 8 月 10 日，最新穩定版確實仍是 v2.0.0，而且它不包含停止日誌流的提交。Clash Party 隨後在 2026 年 8 月 11 日發布 v2.0.1；官方標籤已經包含提交 5532a851，因此不再需要依賴原始碼建置來取得這項修復。
v2.0.1 的發布說明沒有單獨點名日誌頁記憶體問題，所以升級後仍應重複本文的十分鐘前後對照。只有離開日誌頁後應用側記憶體恢復穩定、Mihomo 轉發正常且退出能夠恢復系統網路，才算在自己的環境中完成驗證。
不同版本選擇的邊界
| 選擇 | 能解決什麼 | 需要接受的限制 |
|---|---|---|
| 升級到 v2.0.1 或更高穩定版 | 獲得停止殘留日誌流的提交 | 目前穩定版為 v2.0.2；仍需用同一設定和負載完成前後對照 |
| 保留 v2.0.0 並避開日誌頁 | 降低觸發已知問題的機會 | 需要用連線頁或簡短重啟代替長時間看日誌 |
| 降級到 1.9.6 | 不能可靠避開該問題 | 舊版同樣有復現，還會失去 2.0.0 的其他改進 |
還原測試，並驗證記憶體趨勢真正停止
如果升級後打不開、設定遷移異常或代理不可用，先完整退出並保留現有資料目錄，從 Clash Party 官方 Release 重新安裝目前穩定版 v2.0.2，再匯入之前的設定備份。若必須還原到舊版，應同時記錄版本與資料目錄相容性，不要用新目錄直接覆蓋唯一備份。
v2.0.1 已包含日誌流修復提交，但仍要重複同一組十分鐘對照。真正的驗收不是「新版本能啟動」，而是進入日誌頁、離開頁面後，應用側記憶體回到可穩定的趨勢，同時 Mihomo 轉發和退出恢復都正常。
完成檢查的驗證清單
- 已經分別記錄 Clash Party 應用處理程式組與 Mihomo 核心的記憶體趨勢
- 從未開啟日誌頁的基線與開啟後離頁的趨勢可以重複比較
- 完整重啟並避開日誌頁後，記憶體不再沿原趨勢持續增加
- 訂閱、策略群組、系統代理或 TUN 仍能完成實際網頁請求
- 沒有把 v2.0.0 寫成已包含提交 5532a851 的修復版
- 已從官方 Release 安裝 v2.0.1 或更高穩定版（目前為 v2.0.2），並在升級前備份設定
- 提交 issue 時已移除訂閱連結、節點密碼、控制器 secret 與私人網域