补查：内存暴涨形态（两轮 609MB/957MB，一轮被 GC 救回、一轮被杀；与会话活跃期严格同步，约 27-31KB/事件；非泄漏、非队列积压）＋ 报告补「二之二」节并细化未坐实项

daemon-异常终止取证-20261009.md

@@ -32,6 +32,24 @@
 
 ---
 
+## 二之二、内存暴涨的形态（关键：两轮暴涨，一轮被救回、一轮没赶上）
+
+`[DaemonMemWatch]` 每分钟一读，逐条摘录：
+
+- 第一轮：`16:20 heap=309MB` → `16:21 526MB` → `16:22 551MB` → `16:23 592MB` → `16:24 **609MB**`（峰）→ **`16:25 掉回 132MB`**。
+- 平稳期：`16:26–16:41` 稳定在 **132–135MB**，17 分钟几乎不动。
+- 第二轮：`16:42 149MB` → `16:44 185MB` → `16:48 143MB` → `16:50 160MB` → `16:51 **444MB**` → `16:52 **957MB**` → `16:53:38` 被杀。
+
+**要点一：不是缓慢泄漏。** 16:25 从 609MB 掉回 132MB，说明 V8 能回收 —— 它是**突发分配**，只是第二次没来得及回收进程就被终止了。
+
+**要点二：与「会话活跃」严格同步。** 事件计数（`Conversation event push summary` 的 `received`）在 `16:45／16:46／16:47` 三条**完全相同**（1622136），即该时段零事件，同期内存 175–185MB 平稳；`16:48` 起事件转为递增（+1117 → +3323 → +9097 → +16869 → +18727 每分钟），内存同步起飞。`16:48:08` 正是一个后台会话的启动时刻。
+
+**要点三：不是队列积压。** `pendingEvents: 0`、`maxPendingEvents: 112` 全程不变，事件并没有堆在推送队列里。
+
+**换算比例**：16:51 段约 **31KB／事件**、16:52 段约 **27KB／事件** —— 两段一致，但**这是相关关系，不是已证因果**（见第六节）。
+
+---
+
 ## 三、证据与复现命令
 
 ### 1、内存暴涨
@@ -104,4 +122,9 @@ grep "DaemonLog] session started" <logs>/daemon.log
 
 ## 六、未坐实项（如实标注）
 
-**daemon 内存为什么会涨到 1GB** —— 日志只显示 `Conversation event push summary {"received":1652542 → 1671269}`（累计事件百万级），但这**不足以断定是事件积压所致**。要定这个因，需另做一次带堆快照的复现。本报告不对此下结论。
+**「到底是谁占了那些内存」我没有坐实。**
+
+- 会话自己的 SDK 日志（`logs/<日期>/sdk/conversations/<sessionId>.log`）**只有 499 行、约 199 条事件**（覆盖该会话全部 331 秒），**解释不了 4.9 万条**的 `received` 增量 ⇒ 说明存在一条**不进会话 SDK 日志的事件通道**，我没能定位它的落点。
+- 因此第二节末尾那个「27–31KB／事件」只能算**相关**，不能算因果 —— 内存里完全可能有其它占用与事件速率同步起伏。
+- 要定这个因，唯一可靠的办法是**复现 ＋ 抓 V8 堆快照**（heap snapshot），看增长集中在哪个对象类型。本报告不对此下结论。
+- 另注：`toolThrottleFramesByTool` 里 `Bash` 32206 ／ `Write` 30346 ／ `Edit` 13162 是个**有界指标**（反映被节流的工具帧数），不要把它当内存占用读。