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

.workbuddy/memory/2026-10-09.md

@@ -209,6 +209,38 @@
 
 - ⛔ 只读取证，**未动任何文件、未改任何配置**（`daemon.log`／`Crash-Log/`／宿主库均为只读访问）。
 
+## 06:41 · 补查：内存**为什么会暴涨**（用户追问「为什么内存会暴涨才是问题」）
+
+### 一、完整内存曲线（daemon 53940，`[DaemonMemWatch]` 每分钟一读）
+
+**两轮暴涨，一轮被救回、一轮被杀**：
+
+- 第一轮：`16:20 heap=309` → `16:21 **526**` → `16:22 551` → `16:23 592` → `16:24 **609**`（峰）→ **`16:25 掉回 132`**（V8 GC 成功回收）。
+- 平稳期：`16:26–16:41` 稳定在 **132–135MB**（17 分钟几乎不动）。
+- 第二轮：`16:42 149` → `16:44 185` → `16:48 143` → `16:50 160` → **`16:51 444`** → **`16:52 957`**（rss 1162MB）→ `16:53:38` 被杀。
+
+### 二、与「会话活跃」严格同步
+
+- 事件计数（`Conversation event push summary` 的 `received`）：`16:45／16:46／16:47` 三条**完全相同**（1622136）＝ 该时段零事件，同期内存 175–185MB 平稳。
+- `16:48` 起转为递增：**+1117 → +3323 → +9097 → +16869 → +18727**（每分钟），累计到 1671269。
+- 🔴 **`16:48:08` 正是 `a257d30f` 起跑的时刻** ⇒ 事件与内存**同步起飞**，且两者都在加速。
+- 换算比例稳定：16:51 段约 **31KB/事件**、16:52 段约 **27KB/事件**。
+
+### 三、排掉的两个误判
+
+- ⛔ **不是稳定内存泄漏**：`16:25` 从 609MB 掉回 132MB ⇒ V8 能回收，属**突发分配**而非缓慢泄漏。
+- ⛔ **不是队列积压**：`pendingEvents: 0`、`maxPendingEvents: 112` 全程不变 ⇒ 事件没在推送队列里堆着。
+
+### 四、⚠️ 仍未坐实：到底是谁占的内存
+
+- 会话自己的 SDK 日志（`sdk/conversations/a257d30f-*.log`）**只有 499 行 ≈ 199 条事件**（覆盖 331 秒），**解释不了 4.9 万条**的 received 增量 ⇒ 说明还有一条**不进会话 SDK 日志的事件通道**，我没找到它的落点。
+- 已取读数：`toolThrottledFrames`（53940）＝ **462040**、`toolThrottleCoveredWins`＝455416；`toolThrottleFramesByTool`（73936 累计）里 `Bash` 32206／`Write` 30346／`Edit` 13162／`send_automation_result` 5401／`Read` 2778。
+- ⇒ 「27–31KB/事件」是**相关关系，不是已证因果**。要定因只有一条路：**复现 ＋ 抓堆快照**。⛔ 不编。
+
+### 五、可下的结论（一句话）
+
+**内存暴涨的模式是：会话活跃期（尤其大文件读写）触发事件洪峰，daemon 内存随事件速率同步倍增；而 V8 能否回收是随机的 —— 16:25 收回了、16:53 没来得及就被杀。** 所以问题不在「内存高」，在 **「一个会话周期就能把 daemon 推高 6 倍（160→957MB），且回收时机不可控」**。
+
 ## 06:30 · 结果检查第 32 棒 —— 锁已释放，本轮零派活
 
 - 本棒（自动化 `c9779455`，第 32 棒）现取五样：`state.py` 仍不存在、`taskgraph.json` 仍不存在、台账 16 条（15 done ＋ 1 blocked）、`lifecycle`＝进行中、`acceptance` 3 过 ＋ 1 不过。