任务管理器里 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（杀毒实时扫描内核进程很常见，加白名单）。

优化完重启一次软件让所有参数生效，再用任务管理器观察半天的曲线，比盯瞬时值更能说明问题。