2026-09-04 生产 OOM 宕机 2.5 小时。内核日志:
  Killed process (node) anon-rss:6,321,668kB(6.03GB) total-vm:16.7GB
机器 14GB。进程被杀后整机 swap 抖死,sshd 与 Web 全部无响应,靠人工重启才能恢复。
docker-compose.prod.yml 那段注释 2026-08-26 就写过「这是止血不是根治:池子还在涨,
8G 迟早也会到顶」—— 那天到了。

## 病根不是"没分块",是"不释放"

取数早就是 CHUNK=2000 一块(prefetchForBatch 内),但**产物累积**在跨全量存活的 Map 里;
runPool 的闭包又把 latest/persona/visit/logRows 全部 context-allocate,
V8 要到 runAllForHost 整个 frame 结束才可能回收 → 第 3 步扫全池时它们全还在,那一下就是峰值。

堆账(550,049 命中患者 / 约 96 万条 hit,按 V8 对象布局建模):
  latestByPatient 1.93GB + hitsByPatient 1.06GB + persona/visit 0.14GB
  + activePlans 0.09GB + logRows 0.07GB ≈ 活跃保留 3.3GB,实测 RSS 6.03GB(≈1.8×)

## 改动

· prefetchForBatch 拆成两半:
  - prefetchSnoozeAnchors(scope, now) —— **整轮一次**。它的代价跟"终态且冷静期未到期的
    计划数"走、与患者数无关(生产实测全库 106 行)。拆出来是让这条纪律在类型上也成立:
    它拿不到 patientIds,想塞进批循环也塞不了。
  - prefetchOneBatch(scope, ids) —— 每批一次,删掉内部的 CHUNK 循环,切批权交给调用方。
· 写入段改成端到端批循环:每批 预取 → runPool 写库 → createMany 日志 → 释放。
  hit 的所有权交给本批局部数组后立刻 hitsByPatient.delete(pid),
  批末连同 latest/persona/visit/logRows 一起出作用域回收。
· 新增 resolvePlanBatchSize():默认 2000,夹在 [1, 20000](上限守 PG 32767 bind ——
  latest/persona 走 patientId in ids),**显式传 0 = single-shot 回退开关**
  (照 cold-import 的 resolveCohortBatchSize 同一形状)。
· 每 5 批 + 末批打一行 rss= / heapUsed= / heapTotal=(rss 沿用 cold-import 字样便于并排 grep;
  判 8G 堆余量只能看 heapUsed,rss 含 Prisma Rust 引擎与碎片)。

## 唯一的硬全局依赖,以及它的坑

第 3 步 stale-close 拿本轮命中集对整个召回池取补集(`!hitsByPatient.has(pid)` → supersede)。
分批后 hitsByPatient 被逐批清空 ⇒ 改用跨批累加的 `hitPatientIds` Set(只存 id,约 54MB)。
⛔ 第 3 步**必须等所有批跑完再跑一次**。搬进循环里 = 每批把其他批的患者判成"信号消失"
   → 整池 supersede + 每条认领单一条 auto_release,**而且不报错**,
   那行「本轮关闭 N 条无信号 plan」的日志反而会解释成「这不是 bug」。
⛔ 循环体里**不加 try/catch**:今天的语义是"selectHits 抛错发生在任何写之前 → 整轮中止、
   第 3 步不跑";分批后前 N 批已落库,吞错"把剩下的批跑完"会让第 3 步拿着残缺命中集去关池子。

## 测试

新增 describe.each 覆盖 PAC_PLAN_BATCH_SIZE ∈ {0,1,2,3,2000},同一 fixture 各跑一遍,
断言引擎返回八个字段 + plan 终态 + 日志行**逐字段一致**,直接编码「结果与批大小无关」。
**为什么必须新加**:既有 20+ 条用例每个只有 1~4 个患者、默认批 2000,永远只有一批 ——
分批写错它们全绿。batch=1 是最凶的一档,同时压测跨批不误关 / touchedPlanIds 按批等价 /
snooze 外提后仍被每批查到。fixture 里特意放了一个本轮 0 命中的 p9 压 stale-close。

有牙验证:把第 3 步判据改回 hitsByPatient.has(分批后已清空)→ plansClosed 0→3、
active 与 assigned 双双变 superseded,多条用例立刻红。

## 预计效果与未做的部分

峰值从"latest+hits+logRows 同时在堆"的堆叠拆成单批驻留,预计 3.3GB → 约 2.1GB。
⚠️ 这一级**不碰任何 SQL、不碰 selectHits**,08-30 那根 ×2.31 的并发杠杆与 work_mem 收益
   一个字节不动。但 hitsByPatient 仍在第 1 步满载(1.06GB),峰值仍与命中总数线性相关。
   要真正解耦需要二级(患者域分区 selectHits),那要改 SQL 且必须先在生产标定
   11×P 次子场景查询的墙钟 —— 生产当前宕机,标不了,另开。
⚠️ 第 3 步的 activePlans findMany 仍是无分页全池扫(约 94MB,占比 3%)。改键集分页有真实风险:
   plan-engine-stale-close.spec 的 findMany mock 忽略 take/orderBy/id.gt,分页写错在 CI 里全绿。
   单独一件事做,别和本次混。
⚠️ PAC_PLAN_BATCH_CONCURRENCY 从来没被 withCohortDerivedPool 算进连接池(2026-09-02 已因
   漏算一次导致健康日报连续三天超时)。本次不改,记在这。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>