dag import后为何仍会被GC？

CAR文件成功导入，只能证明文件中的区块已经被写进当前Kubo仓库；它不自动证明根下的DAG完整，也不保证每一个孤立块都得到长期保护。最危险的操作是看见命令退出码为零，就立刻执行repo gc并删除原始备份。恢复流程应把“块已进入仓库”“根已固定”“目标可完整读取”和“未被根引用的块如何处置”分成四个验收项。

导入动作究竟写入了什么

ipfs dag import会导入CAR中存在的全部区块，而不只导入从CAR根可达的区块。

dag import读取CAR并写入其中实际包含的全部区块，不以“是否从CAR根可达”作为写入条件。也就是说，文件里若带有孤立块、多个不相干子树或尚未被根引用的中间结果，它们同样可能进入blockstore。这个特性便于批量迁移，却也意味着导入数量不能直接当作业务DAG的完整块数。

验收时先保存CAR文件哈希、文件大小、声明的根列表、Kubo版本和导入输出。若同一CAR在多个节点恢复，比较的对象应是根、块集合和读取结果，而不是只比较终端最后一行文字。原始CAR在完成独立核验前仍是唯一可回退材料。

默认Pin保护的是根路径

默认会在所有CAR处理完成后固定CAR头中的根CID；未从根可达的其它区块不会因此自动被固定。

默认流程会等所有输入CAR处理完，再尝试固定CAR头中的根CID。递归Pin能保护从该根可达的区块，但不在根可达集合里的块不会因为“同在一个CAR”而自动获得保护。若文件包含多个根，就应逐根记录固定结果，不能用第一个根成功替代整批验收。

检查对象	能证明什么	仍不能证明什么
导入退出码	命令未报告整体失败	每个业务对象都可读取
根CID存在	根块在本地	所有后代块齐全
递归Pin存在	可达块受Pin保护	CAR内孤立块受保护
文件读取成功	抽样路径可解析	其它根或路径全部完整

partial CAR为何不能强行固定

使用local-only导入部分CAR时会隐含关闭pin-roots，因为缺块可能使根DAG不完整。

local-only用于不向网络补块的尽力导入。面对部分CAR，根下可能缺少链接目标，因此该模式会隐含关闭pin-roots。这个行为不是“Pin失效”，而是避免把一个无法完整遍历的根误标成已得到可靠递归保护。生产脚本若同时传入互相冲突的期望，应以命令实际语义和输出为准。

部分恢复要先列出缺块，再决定从其它CAR、可信节点或原始数据补齐。不要通过创建直接Pin把错误暂时隐藏：直接Pin只能保护根块本身，无法证明子树完整。补块后重新执行递归Pin与读取验收，才形成可审计的恢复闭环。

GC之前做四层验收

Kubo垃圾回收会清理没有被Pin保护的本地区块，因此导入成功不等于每个导入块都能长期保留。

第一层核对根：确认预期根全部出现在导入结果中。第二层核对保护：用pin ls和pin verify确认递归Pin没有坏链。第三层核对结构：对目标根执行dag stat或等价遍历，记录块数与累计规模。第四层核对内容：抽样读取关键文件，并与业务侧哈希、清单或可重建结果比较。

只有这四层都通过，才考虑在副本环境做一次GC演练。演练前后再次读取同一组根和样本；若业务确实需要CAR内的非根块，必须为它们建立明确的根、Pin或MFS引用，而不是依赖“刚好还在blockstore”。

失败时按证据回退

根Pin失败时保留原CAR和失败日志，不要先GC腾空间；结构遍历缺块时记录第一个缺失CID及其上游路径；读取内容不符时检查CAR来源、CID与应用层解码，而不是重新导入同一文件期待结果改变。共享仓库还要冻结并发GC，避免排查期间证据继续变化。

CAR格式与备份核验可参考CAR备份完整性核验，递归Pin损坏可参考pin verify坏Pin排查，垃圾回收范围见repo gc清理边界。本文讨论的是本地恢复与持久化操作，不承诺远端提供者可用，也不构成数字资产投资建议。

恢复资料与边界

Kubo dag import：导入范围、pin-roots、local-only与处理顺序。
Kubo repo gc：垃圾回收删除未固定对象的边界。
IPFS persistence：Pin、MFS与持久化概念。

资料访问时间为2026-08-15。仍需保留的边界：CAR内区块是否构成完整DAG取决于文件内容与本地已有块，不能仅凭命令退出码断言恢复完整。