本文目录
先确认内存上涨是不是由日志页触发
本文处理的是一个边界很清楚的问题：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.0 并避开日志页 | 降低触发已知问题的机会 | 需要用连接页或简短重启代替长时间看日志 |
| 降级到 1.9.6 | 不能可靠避开该问题 | 旧版同样有复现，还会失去 2.0.0 的其他改进 |
回退测试，并验证内存趋势真正停止
如果升级后打不开、配置迁移异常或代理不可用，先完整退出并保留现有数据目录，从 Clash Party 官方 Release 重新安装已核验的 v2.0.1，再导入之前的配置备份。若必须回退到旧版，应同时记录版本与数据目录兼容性，不要用新目录直接覆盖唯一备份。
v2.0.1 已包含日志流修复提交，但仍要重复同一组十分钟对照。真正的验收不是“新版本能启动”，而是进入日志页、离开页面后，应用侧内存回到可稳定的趋势，同时 Mihomo 转发和退出恢复都正常。
完成排查的验证清单
- 已经分别记录 Clash Party 应用进程组与 Mihomo 内核的内存趋势
- 从未打开日志页的基线与打开后离页的趋势可以重复比较
- 完整重启并避开日志页后，内存不再沿原趋势持续增加
- 订阅、策略组、系统代理或 TUN 仍能完成真实网页请求
- 没有把 v2.0.0 写成已包含提交 5532a851 的修复版
- 已从官方 Release 安装 v2.0.1，并在升级前备份配置
- 提交 issue 时已移除订阅链接、节点密码、控制器 secret 与私人域名