这次日志（你开着 debug）直接指认了问题，没靠猜。
日志里的证据
记录位置：…数学物理方法….pdf 第 226 页 → 第 226 页（差异：scrollTop: 638→635）
记录位置：…第 226 页 → 第 226 页（差异：scrollTop: 639→573） ← 一秒后又是它
PDF 阅读位置表已对平：6 条 ← 一分钟刷几十行
页码从头到尾没变，变的是 scrollTop —— 那是 pdf.js 在渲染过程中自己微调滚动位置。而我们把这个抖动判成「表变了」，于是每秒把整张 pdfjs.history 写一遍。
这一点值得单独说：localStorage 是同步 IO，占的是主线程；而 PDF 的 canvas 绘制也在主线程。 你截图里那个「页码显示 28/93、画面却全黑」，与这种持续阻塞是吻合的。
改了三处
① 我们不再写 pdfjs.history（除了打开前那一次）。
pdf.js 每次滚动本来就会把整张表写回去，而它的 database 就是我们交给它的共享表 —— 它写的时候天然带上全部条目。我们那次写是纯重复劳动。现在只保留「打开 PDF 之前写一次」，让 pdf.js 自己读到位置去恢复；其余时间只做一件事：让所有打开的视图都指向同一张表（这才是「多开 PDF 位置互相覆盖」的真正解法）。
② 补拍定时器加了硬上限与去重。
上限 10 个，超了直接丢弃并记账；id 存进 Set，执行时自己删掉。
之前那段是「数组超过 64 就截短到 32」—— 但被截掉的 id 没有 clearTimeout，那些定时器照样执行。所以那个上限是个假象。
③ layout-change 加 400ms 节流。
切视图、视图重建都会连着触发它，而它一次就排 6 个补拍。
顺便让限制自己会说话
被丢弃的补拍数、被节流的 layout 次数、以及「一秒内跑了太多次补拍」，各会写一行日志。下次你再反馈，我直接读这几行，不用再推理。
说清楚边界
这些都没有被证明是 4GB 的原因。 我能做的是把我们这一侧的浪费和失控都收干净 —— 每秒一次同步写盘、定时器无限增长，这两条都是实打实的（都有日志）。至于到底是 app 还是插件，仍然需要那次对照实验：
把「View Memory」禁用 → 重启 Obsidian → 快速打开那两个 PDF、来回切几次
- 还崩 / 还涨 → 是 Obsidian + pdf.js 自己的事（两个大部头 PDF 双开本身就是重活）
- 不崩了 → 是我们的锅，这轮加的日志会指出是哪一段
回归
合并套件 44 → 54 项，视窗侧 199 项，全绿。
其中最关键的一条：让一个 PDF 视图的 scrollTop 连抖十二拍，断言 localStorage 一次都没被写 —— 先验过红（把「每拍写一次」塞回去，它立刻报「写了 12 次」）。