实验室共享大型文件时，校验值应该放在哪个环节

跨地区团队传输显微图像、质谱原始数据或模型输出后，通常会问：“文件有没有坏？”有人在压缩包上传完成后计算一次SHA-256，把结果贴进消息，就认为交接结束。可是接收者解包后少了一层目录，某个大文件仍能打开，模型结果又经过格式转换；这时那一个总哈希已经回答不了问题发生在哪一层。

校验值不是传输结束后才补写的一串字符。它应在源文件冻结时建立基线、随逐文件清单交付、由接收端独立复算，并在解包、格式转换或长期归档后为新对象重新生成；每个值只对明确算法、文件版本和处理阶段负责。

第一个节点不是上传，而是冻结源文件

文件仍在采集、导出或同步时，不应计算正式交付校验值。仪器软件可能继续追加数据，分析任务也可能覆盖输出；此时产生的哈希只代表计算瞬间的字节，不能作为最终基线。

先结束写入，确认文件句柄关闭，再为交付集合分配稳定版本ID。记录数据集、样品或任务标识、文件数量、总字节数、责任者和冻结时间。若后来必须修正文件，新建版本，不用相同名称悄悄覆盖。

FAIR原则要求数据和元数据具有稳定标识，并让元数据明确指向所描述的数据。这里不必追求复杂编码，关键是版本ID不随目录位置改变，而且清单、说明和结果都引用同一对象。

源端基线要覆盖每个实际文件

BagIt规范把交付内容放在payload，并要求manifest把每个payload文件恰好列出一次，以相对路径连接所用算法和校验值。实验室可以采用同样的轻量结构：每行记录对象ID、相对路径、大小、算法和SHA-256。

只给压缩包一个总哈希，可以确认整个传输容器是否改变，却不能说明解包后内部文件是否齐全，也无法指出具体哪一项损坏。总包校验适合判断传输容器是否变化，逐文件manifest才能定位遗漏或损坏的具体对象。

清单生成后再比较一次目录集合。目录中有而清单没有、清单有而目录缺少、同一路径重复出现，都先修正再上传。校验值只保护被列入范围的对象，不会自动发现团队忘记纳入的原始文件。

接收端必须独立复算

把源端的manifest和数据一起发送，不代表验证已经完成。接收端应先取得预期清单，再从自己的副本重新计算；直接复制发送者输出的“成功”状态，只能证明消息到达。

接收检查分两层。第一层比较预期和实际文件集合、路径、大小，回答对象是否收齐；第二层逐项复算校验值，回答收到的字节是否与源端冻结版一致。

BagIt把这两个状态称为complete与valid：完整要求必需元素存在、manifest列出的文件都在且全部payload被列出；有效还要求每个校验值验证成功。文件集合一致回答是否收齐，校验值一致回答已收文件的字节是否相同。两者不能只用一个“传输成功”取代。

分块与断点续传仍要回到同一清单

大型文件常分批传输或断点续传。每一批可以记录进度和临时结果，但最终验证必须回到同一个冻结版本的完整manifest。恢复前先确认源文件没有在中途改变，否则旧块和新块可能来自不同版本。

失败重传只补传差异对象，不必重新移动全部资料。接收记录列出缺失、大小不符、哈希不符和路径冲突，并把修复后的复算时间写入回执。旧失败状态保留，避免后来只能看到一次成功却不知道发生过什么。

跨Windows、macOS和Linux时还要检查大小写、Unicode规范化、保留文件名和路径分隔符。BagIt规范特别提醒这些互操作差异。若平台必须改名，保存明确映射，不在没有记录的情况下让路径与manifest失去对应。

解包以后，校验对象已经分成两层

若交付的是压缩包，接收端先验证压缩包哈希，确认传输容器未变；解包后再按逐文件manifest验证payload。前者失败要重新取得容器，后者失败则可以定位是清单、路径、解包或内部文件的问题。

归档包能够解开并不等于内部有效，内部逐项有效也不证明所有研究资料都纳入范围。接收回执分别写“容器一致”“对象收齐”“逐文件一致”，不要合并成一句模糊结论。

若只搬运一个不可拆分、接收后不会解包或转换的归档对象，总包校验可满足传输检查；只要团队还要单独读取内部文件，就应保留逐文件层。

格式转换后要产生新版本和新校验值

质谱格式转换、影像重编码、表格从专有格式导出为开放格式，都会产生不同字节。转换后的哈希不可能与原文件相同，这不是传输损坏，而是新对象诞生。

为转换结果分配新对象ID，计算新校验值，并记录使用哪版输入、转换工具、版本、参数、时间和执行者。PROV-O用实体、活动和责任者描述这类关系，也能表达生成、使用、衍生和修订。

源端冻结后的哈希建立字节基线，接收端独立复算发现传输变化；对象转换后通过新ID、新哈希和来源关系连接父版本。不要删掉原文件后只留下转换结果，否则以后无法判断差异来自传输、转换还是分析。

文件能打开是另一项检查

哈希一致的文件仍可能缺少必要元数据、使用错误格式版本，或需要接收端没有的软件。完成字节检查后，再挑代表性文件做可用性验证：影像能否读取维度和位深，质谱文件能否列出运行元数据，模型输出能否对应输入任务。

可用性验证与校验值作用不同。前者检查格式和工作语境，后者检查字节。即使全部文件都能打开，也可能各自来自不同版本；即使全部哈希都一致，也可能源文件本来就不完整。

交付说明还应包含来源、实验条件、许可和适用边界。FAIR原则把详细属性、许可、来源和领域标准列为可再利用条件；这些内容不能塞进一串哈希，却决定接收者能否正确理解资料。

长期归档要定期重算，但不改历史基线

进入长期存储后，保存最初冻结清单和每次巡检记录。定期从存储副本重新计算，与同一对象版本的基线比较；出现差异时，先隔离副本并从可信备份恢复，不直接覆盖所有副本。

存储迁移时，迁移前后各核验一次。若只是搬移路径，内容哈希应保持；若重新压缩、重新编码或改变文件内容，则按新对象处理。每次巡检记录算法、工具版本、时间、位置和执行者，才能分辨哪一次检查针对哪份副本。

算法未来若需要更换，可以在同一冻结对象上追加新算法的值，同时保留旧值和产生时间。不要无说明地替换字段，让历史接收记录失去可解释性。

校验值没有提供的保证

BagIt说明manifest可对数据损坏提供高置信完整性检查，但不用于抵御主动攻击。知道两个副本字节相同，不等于知道发送者身份，也不等于内容安全。需要来源认证时，应另用签名、受控访问和责任记录。

完整性校验不提供来源认证，也不评价实验内容、许可、格式语义或科学结论。恶意文件可以拥有完全正确的哈希，错误的实验输出也能在传输中保持逐字节一致。

最终回执应准确写成：哪个版本、哪些对象、用什么算法，在何时由谁复算并通过；格式与代表性可用性检查结果另列。校验值的价值不在于让团队安心，而在于把“哪里发生变化”缩小到一个可以处理的阶段。

资料来源

• RFC Editor / BagIt authors：《The BagIt File Packaging Format (V1.0)》，发布或更新于 2018-10-01
• Scientific Data / FAIR原则作者组：《The FAIR Guiding Principles for scientific data management and stewardship》，发布或更新于 2016-03-15
• World Wide Web Consortium：《PROV-O: The PROV Ontology》，发布或更新于 2013-04-30