「空闲内存 < 200MB」这条预算已经破了：实测 155–238MB

[Spc-jgs]

实测（2026-09-06，.app，会话恢复了几个标签 + 一个终端）

进程	线程	Physical footprint
lite-ide（我们自己的）	8–10	32 MB
WebKit.WebContent	4	106–173 MB
WebKit.GPU	6–8	16–29 MB
WebKit.Networking	3–4	4.5 MB
合计	21–26	155–238 MB

量法：vmmap --summary <pid> | grep "Physical footprint"，不是 RSS
（RSS 会把共享的框架重复计进每个进程）。

问题

docs/ARCHITECTURE.md §7 写的是「空闲内存 < 200MB」，而实测在开了几个
标签之后就会破。README 里那条「常驻内存 98 MB（含 mmap 引擎 + WebKit 两个
进程）」更是陈旧的 —— 实际是 4 个进程，而且数字差一倍多。（README 和
ARCHITECTURE 的数字已经在这一轮改成实测值了，但预算本身还没决定怎么办。）

两件事要分开看

Rust 侧只占 32 MB，涨的部分全在 WebKit 的渲染进程上。 也就是说这不是
日志引擎的问题 —— mmap 那套是对的，logengine 的索引内存实测 69.8 KB。
涨的是前端：CM6、xterm、67 个语言包里被真正加载的那些、以及每个打开的文档。

可能的走向（都没验过，先记着）

1. 改预算的口径。 「空闲」这个词对这个应用是不成立的 —— 会话恢复会把上次
   的标签开回来，它没有真正的空闲态。改成「开 N 个标签 + 1 个终端时 < X MB」
   这种可量的口径。
2. 量一下 WebContent 里到底是谁。 Safari 的 Web Inspector 能连上
   WKWebView（需要在 tauri.conf.json 里开 devtools 的 release 构建），
   先看堆快照再谈优化。
3. 关掉的标签有没有真的释放。 {#key active.id} 会销毁重建编辑器实例，
   但 CM6 的 state / 语言包缓存是不是跟着走，没查过。这条最值得先查——
   如果是泄漏，那 155→238 的漂移就有解释了。

先做 3，它是唯一可能是 bug 而不是「本来就要这么多」的一条。

[Spc-jgs]

2026-09-07 那轮审查里挖到两条具体机制，第 3 条「关掉的标签有没有真的释放」
有一半答案了，而且方向和这个 issue 猜的相反 —— 在 Rust 侧，不在前端。

一、关掉日志标签，后台还在扫完整个文件

LogFile::open（logengine/src/lib.rs）起两条后台线程（索引 + 级别探测），
两条都攥着 Arc<Mmap>，而且没有取消开关。close_log 只是把句柄从表里
摘掉 —— 线程照样把整个文件扫完，mmap 和 LevelMap 一直吊到那时候。

对照：同一个 crate 里的 FilterTask 是有 cancel() 的，set_filter
换条件时就取消旧的。所以这不是设计取舍，是漏了。

打开一个 1GB 日志、看一眼、关掉 → 后台还要 memchr 完 1GB、建完约 5MB 的
LevelMap。连开几个就是几条线程叠着扫。

修法应该和 FilterTask 一样：LogFile 带一个 AtomicBool，两条线程每块
循环判一次，close 时置位。

二、语言包缓存永不释放（这条更像那个「155 → 238 漂移」）

src/lib/editor/langs-load.ts 里是个 module 级 Map，只 set 不 evict。
67 个语言包，打开过哪种就常驻哪种（import() 进来的模块本身也一样永不卸载）。

它是单调增长但有上界（最多 67 个），形状比「泄漏」更像这个 issue
观察到的漂移。没量过数字，属于待验证 —— 但它应该排在「量 WebContent 里
到底是谁」的第一个怀疑对象。

三、顺带排除掉一条

第 3 条里写的「{#key active.id} 会销毁重建编辑器实例」—— 查过了，
正因为有 {#key}，同一时刻只存在一个 CM6 实例，所以不会攒 N 个视图。
代价在别处：每次切标签都要重建整棵语法树，大文件来回切是有开销的
（那是性能问题，不是内存问题）。

[Spc-jgs]

「日志后台扫描不可取消」这条修了，但先更正我自己上一条评论里的一句话。

更正：量级没我说的那么大

上一条我写的是「打开一个 1GB 日志、看一眼、关掉 → 后台还要 memchr 完 1GB、
建完约 5MB 的 LevelMap」，听着像个内存黑洞。量了之后不是：

级别扫描实测	51.8MB / 14.9ms（M 系列、热缓存，约 3.5GB/s）
折算 1GB	约 0.3 秒（冷缓存更慢，那时是 I/O 说了算）

所以这条修的是「白烧零点几秒 CPU、mmap 多吊一会儿」，不是大出血。

结论上的影响：这条不该被当成这个 issue 里 155 → 238MB 那个漂移的
解释。那个大概率还是在前端 —— 我上一条评论里提的第二个机制
（langs-load.ts 那个只 set 不 evict 的语言包 Map，67 个包加载即常驻）
形状更像，但同样没量过。下一步该做的仍然是这个 issue 第 2 条：
拿 Safari 的 Web Inspector 连上 WKWebView 看堆快照。

还是修了，理由

• 那活没有任何人要：标签已经关了，结果发布出去也没人读。
• 连开几个大日志就是几条线程叠着扫。
• 同一个 crate 里的 FilterTask 明明有 cancel()（换过滤条件时旧任务立刻停），
  所以这不是设计取舍，是漏了。

开关放在 impl Drop for LogFile，不是给 close_log 加一行调用 ——
调用点会有人忘，Drop 只要最后一个 Arc<LogFile> 没了就一定跑到。
检查粒度：索引每块（16MB / 约 3ms）一次，级别每 64K 行一次。

被取消时不发布结果、也不置 done：半份 LevelMap 会让「这文件里有几条
error」给出一个偏小的答案，比没有更糟。

3.5GB/s 反过来决定了测试怎么写

想验证取消开关，第一反应是「造个大到来不及扫完的文件，drop 掉，看线程多快退出」。
在 3.5GB/s 面前这条路是死的 —— 得造到 GB 级才有窗口，跑一次好几秒、
还要往盘上写一 GB，而且本质上是在赛跑，机器一忙就抽风。

改成把两个扫描循环拎成函数（scan_levels / build_index），
开关预先置位再调用，结果确定，两毫秒跑完：

测试	去掉什么会红
关掉日志文件就置位取消开关	把 impl Drop 掏空
级别扫描被取消时不扫完也不交半份结果	scan_levels 里那句检查
索引推进被取消时立刻返回	build_index 里那句检查

三条逐个验过红。顺带踩到一个假断言：scan_levels 每 64K 行才查一次开关，
测试数据只有几百行的话那个检查一次都不会执行 —— 断言照样绿，什么都没验到。
测试数据的行数必须跨过 65536。

[Spc-jgs]

量了。第 3 条（关掉的标签没释放）证伪 —— 标签确实释放了，没有可测的泄漏。
量法固化成了 scripts/mem.sh。

数据：12 个文件（12 种语言，各 400 行）开关 8 轮

每个数字是 3 次 vmmap --summary 的中位数，四个进程的 Physical footprint 之和。

	峰值	关完
基线（无标签）	—	101.7
第 1 轮	237.6	137.2
第 2 轮	178.8	135.6
第 3 轮	207.6	169.3
第 4 轮	178.1	134.7
第 5 轮	183.9	134.4
第 6 轮	217.3	131.4
第 7 轮	211.1	131.8
第 8 轮	200.2	158.8
再静置 60s	—	135.2

对「关完」序列做最小二乘：斜率 +0.2 MB/轮（即 +0.02 MB/标签），
R² = 0.00，残差标准差 15.4 MB。

第 8 轮（累计开关过 96 个标签）和第 1 轮在同一水平。没有线性泄漏。

三个会让人得出反结论的坑

第一版就是这么被骗的，都写进脚本注释了：

1. 判据不能是「关掉后回落到基线」。 语言包缓存（langs-load.ts 的 Map）
   只 set 不 evict，那是设计 —— 关完不回基线是正常的。真泄漏要看逐轮。
2. 单次 vmmap 读数抖动十几 MB。 一个点读一次的那版，四轮关完值是
   160/125/147/184，看着像在涨，其实是噪声。现在每点读三次取中位数。
3. 第一轮涨的不是泄漏。 那 +80～135 MB 的大头是 12 个 Lezer parser
   的一次性加载 —— 12 个文件全加起来才 428 KB，文档本身占不了这么多。

顺带排除的

App.svelte 里按 path 存东西的容器只有 posByPath / pendingPos /
opening / warnedBig 四个，全是 string → number|bool，12 个标签合计
几百字节 —— 不可能是几十 MB 的来源。Editor.svelte 的 cleanup 里
view?.destroy() 是有的。

这个量法量不到什么

残差标准差约 15 MB，每轮小于十几 MB 的泄漏它看不见。对这条 issue 关心的
量级（155→238 那 83 MB 的漂移）够了；要知道「堆里具体是谁」得上 Safari 的
Web Inspector，那需要带 devtools feature 的构建，mem.sh 给不出来。

所以严格说：这次做的是进程内存测量，不是堆快照。它回答了「有没有泄漏」，
没回答「106～173 MB 的 WebContent 里具体是谁」。

结论：应该走第 1 条（改预算口径）

155～238 MB 不是泄漏，是「WebKit 四个进程 + CM6 + 语言包本来就要这么多」。
实测三个稳态：

• 无标签：约 91～142 MB（同样状态多次启动，波动就这么大）
• 12 个标签开着：178～238 MB
• 关完稳态：131～169 MB

ARCHITECTURE.md §7 那条「空闲内存 < 200MB」有两个问题：「空闲」这个态
不存在（会话恢复会把上次的标签开回来），而且 12 个标签开着时 200MB 必破。

新口径得你定，数据摆在这儿。一个建议的形状：
「开 12 个标签 + 1 个终端时 < 250 MB，无标签时 < 150 MB」——
两个都是可量的，scripts/mem.sh 能直接复跑。

[Spc-jgs]

接上一条。不做 Web Inspector 的 GUI 自动化了 —— 试过一次，代价是把
Safari 的 AppleEvent 接口挂住（对 Inspector 窗口跑 entire contents，
那是几万节点的同步遍历）。换成一个能自动化、能验红的量法。

换掉的是量什么，不是怎么量

scripts/mem.sh 量四个进程的 Physical footprint，噪声比信号大
（同样「无标签」状态多次启动差 40MB），只能回答「有没有线性泄漏」，
而且要跑十来分钟，没法当回归测试。

改成量对象数。前端在 LITE_IDE_DEBUG=1 时每 3 秒往既有的 diag 通道
报一行：

[diag/web] mem editors=0 nodes=136 langs=0

没有 GC 时机的干扰，两次采样完全一致：

状态	editors	nodes	langs
基线（无标签）	0	136	0
3 个标签、3 种语言	1	181	3
关掉全部	0	146	3

editors=1 而不是 3 是对的 —— 编辑器被 {#key active.id} 包着，
同时只有一个实例。关掉后归零，第 3 条的疑问到此有了确定答案。

langs=3 保持不掉是设计（那个 Map 只 set 不 evict，67 封顶）。
把它报出来，是为了让「有没有上限」可以被量，而不是只能读代码相信。

验过红

把 Editor.svelte 的 cleanup 改成不 view.destroy()、把 DOM 搬到 body 上
（模拟「没清干净」这个故障形态），重新打包：

	好版本	破坏版
开 3 个标签	editors=1	editors=3
关掉全部	editors=0	editors=3

不只抓得到「关掉没释放」，连「切标签时旧实例没清掉」都抓得到。

已经变成常驻回归

scripts/smoke.sh 第 ⑫ 条：关掉全部标签之后 editors 必须归零。
现在整个脚本是 22 条断言，0 失败。以后任何一次改动让编辑器漏了，
端到端验收就会红。

默认静默，发布包里不跑

判据是 Rust 侧新增的 diag_enabled（即 LITE_IDE_DEBUG=1），
关着的时候连定时器都不建。不用 import.meta.env.DEV，是因为要量的
正是 pnpm app:bundle 出来的 release 包。

顺带：devtools 也做成了 feature（pnpm app:bundle:devtools），默认不编进去。
Safari 确实能连上（验过），但拍快照那几下得人工点 —— 不自动化它。

这个指标量不到什么

它数的是 DOM。「DOM 清了但 EditorView 被别处引用着」那种纯 JS 泄漏抓不到，
那要 queryInstances（Inspector 专有）或 FinalizationRegistry。

两条证据互补：mem.sh 排除了几十 MB 量级的总量泄漏，这条排除了 DOM 残留。
这条 issue 关心的漂移量级（155→238 那 83MB），两条都覆盖到了。

剩下的仍是第 1 条：预算口径怎么定。 那是产品决策，数据都在上一条评论里。