外站原图采集追踪（2026-04-23，历史快照）

这页只保留 2026-04-23 当时代码库的真实闭环，不再沿用“还差 3 张”之前的中间状态。

2026-04-25 补记： 这页记录的“采集链路如何闭环”仍然有效，但“当前是否还有 backlog”的判断已经有更新版本。 现在的现行基线请看 图片缺口与放置审计（2026-04-25）。

本轮最终基线

基于以下命令的最终输出：

• npm run wiki-images:fetch -- --dry-run
• npm run browser-cache:recover -- --dry-run
• npm run site-images:audit -- --json

当时这轮仓库状态是：

• 241 篇 markdown
• 529 处图片引用
• 用户可见页面本地坏链：0
• 正文外链图片：0
• 官方热链：0
• 外站 exact-source 原图队列：31 项
• 已存在本地 originals：31 项
• 当前缺失：0

这意味着当时“外站原图采集”这条线已经从 backlog 变成闭环。

本轮新增闭环的 5 张 BG Wiki exact-source

这轮通过 Chrome Canary 已有访问记录与浏览器缓存，把新增 5 张 BG Wiki 原图完成了本地化：

对象	本地路径	当前正文页面
Sorrowful Sage	/img/wiki-sourced/originals/sorrowful-sage.jpg	/content/nyzul-isle
Grounds Tome Top	/img/wiki-sourced/originals/grounds-of-valor.jpg	/systems/gov
Rolandienne	/img/wiki-sourced/originals/rolandienne.jpg	/systems/roe
Al'Taieu map	/img/wiki-sourced/originals/altaieu-map.jpg	/content/sea /content/sea-altaieu /content/sea-limbus-roadmap
Rhapsody in White	/img/wiki-sourced/originals/rhapsody-in-white.jpg	/systems/fov /systems/rov

其中：

• Grounds Tome Top
  • 已切到 /systems/gov
• Rolandienne
  • 已切到 /systems/roe
• Sorrowful Sage
  • 已切到 /content/nyzul-isle
• Al'Taieu map
  • 已切到 /content/sea
  • 已切到 /content/sea-altaieu
  • 已切到 /content/sea-limbus-roadmap
• Rhapsody in White
  • 已切到 /systems/fov
  • 已切到 /systems/rov

本轮继续闭环的 2 张 WE ARE VANA'DIEL exact-source

这轮继续沿 Chrome Canary -> Cache_Data/sqldb0 -> 本地落库 的链路，把两张官方原图补进了仓库：

对象	本地路径	当前正文页面
Campaign Ops Added	/img/official-sourced/history/campaign-ops-added.jpg	/content/campaign-ops
Campaign Battles Added	/img/official-sourced/history/campaign-battles-added.jpg	/systems/battle-currencies

其中：

• Campaign Ops Added
  • 用来先立 Campaign Ops 接单柜台语境
  • 不再只靠站内 SVG 硬撑外站场景感
• Campaign Battles Added
  • 放在 battle-currencies 的 Allied Notes / Campaign 段落
  • 只补该段语境，不拿单一子系统图去冒充整页总图

为什么这次能拿下来

本轮真正有效的抓手不是 shell 出网，而是：

1. 用 Chrome Canary 真实打开 BG Wiki 原图 URL
2. 让图片进入浏览器缓存
3. 从 Chrome Canary 的 Cache_Data/sqldb0 里回收图片正文

这条链路之所以之前会卡，是因为旧的 browser-cache:recover 优先走“从 cache 文件直接扫描图片 payload”的路径，容易把 sqldb0-wal 里的错误 payload 当成真图；而真正稳定的 exact-source 数据在 Chrome / Chrome Canary 的 sqldb0 SQLite cache 里。

本轮顺手补的工具能力

scripts/recover-browser-cache-images.mjs

已把恢复顺序改成：

• 优先查询 Cache_Data/sqldb0 / resources / blobs
• 只有 SQLite cache 没命中时，才退回原始 cache 文件扫描

这意味着后续遇到类似 Sorrowful Sage / Grounds Tome Top 这种“URL 已进缓存，但 sqldb0-wal 直接扫描会拿到脏 payload”的情况，不需要再手工抠 blob。

当前结论

站在 2026-04-23 这轮结束时，外站原图采集线的状态已经很明确：

• originals 队列 31/31 已全部存在
• 额外新增 2 张 official exact-source 本地镜像
• browser-cache:recover 当时已经是 31/31
• wiki-images:fetch -- --dry-run 当时已经是 missing: 0
• 不再存在“还差几张 BG Wiki exact-source”这一类 backlog

下轮不该再重复做的事

1. 不要再重复打开这 5 张 BG Wiki 图片页。
2. 不要再把 Sorrowful Sage / Grounds Tome Top / Rolandienne / Al'Taieu map / Rhapsody in White 当成缺图对象。
3. 不要再沿用“当前还差 3 张”之类旧结论。

本轮判断

这轮的关键不是又补了几张图片，而是把“模拟人工访问 -> 浏览器缓存 -> SQLite 回收 -> 正文落库”的链路真正做通了。
这个能力以后还能继续复用，不再只是一次性救火。