照片永远不会在增量抓取里出现 —

抓自己上传的图这条路线上线之后，跑一次增量：一张图都没有。

原因不是代码写错了。图片的 URL 是从广播页面里派生出来的，而增量抓取只重新取水位线以上的页面——那是它省时间的全部办法。所以在这条路线存在之前发的每一张图，都躺在水位线底下，而增量永远不会再去读那些页面。不做别的事的话，它们就永远不会进档案。

这类问题的形状值得记一下：它不是「某次抓取失败了」，它是 「按这个设计，这批数据没有任何路径能被抓到」。重试、重跑、多等一天，都不会让它出现。

不用重抓页面，因为页面已经在档案里了

解法来自这个项目一开始就在守的那条线：原始页面是存下来的。那些广播页面躺在旧档案里，图片的 URL 就在它们的 HTML 里面。所以不需要再问豆瓣要一次——只要把已经存下来的页面重新读一遍、重新算一遍图片 URL，然后只去取那些图片的字节。

这些新捕获的 parent_capture_id 指向的是另一份、更早的档案里的捕获。规范 §6.2.1 明确允许这件事，而它同时还是一个标记：这个捕获是算出来的，不是从一个活页面上读下来的。

这一步没有做成「补抓模式」，也没有单独的命令——它在每一次抓取里都跑一遍。这么定是因为它换来一个很值钱的性质：

抽取器写错了，是可以事后救回来的。改掉抽取器，下一次抓取自动补上前面几次漏掉的东西。

没有「重新扫描」这个开关，用户也不需要知道自己该不该按它。这就是「派生数据随时可以扔掉重算」这句话真正兑现的地方—— 它平时听起来像句架构口号，直到你需要它的那一天。

顺带说一句这条性质的边界：它救得回来的是页面已经在档案里的那些。如果一个页面当初根本没抓，那就没得救，只能重抓。这也是为什么「先把页面原样存住，怎么解读它以后再说」这个顺序不能倒过来。