补查：内存暴涨形态（两轮 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 不过。

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 是个**有界指标**（反映被节流的工具帧数），不要把它当内存占用读。