先区分传输完成与数据可用
浏览器或客户端显示100%只说明传输会话结束，不代表接收端文件与发送端完全相同。断点续传、代理缓存、磁盘空间不足和同名文件覆盖都可能留下可打开但不完整的结果。
发送前应记录文件大小与SHA-256摘要；接收后重新计算并比较。摘要一致可以证明字节级内容相同，但不能证明样本标签、参考版本或实验设计正确。
FASTQ和BAM需要不同层次的检查
FASTQ可以检查压缩包完整性、读段数量、配对文件对应关系及质量编码。BAM除了文件摘要，还要检查header、参考序列、排序方式和配套BAI索引。索引来自另一个版本时，查看工具可能报错或显示缺失区域。
大型项目不宜只靠文件名判断样本。样本编号、run编号、lane、读取方向和生成时间应进入项目清单，避免同名重跑文件被静默替换。
加密不替代交付记录
传输加密保护通道中的内容，但无法修复发送前已经损坏的文件，也无法说明谁有权使用数据。项目仍需保存发送者、接收者、用途、存储位置、保留期限和失败重试。
HK-BEUP客户端应先用小文件验证路径和权限，再传输大文件。正式交付前抽查解析结果和统计摘要，能够发现摘要一致但项目语义错误的情况。
网络稳定时也可能交付错误
最常见的问题未必是断线，而是任务选错文件、配对顺序颠倒或上传了旧版本。高速通道会更快地把错误送到接收端，因此发送清单必须在启动任务前完成。
对于多人项目，可以让提交者与接收者分别核对样本数量、文件角色和目标目录。两次核对关注的是项目语义，文件摘要关注的是字节一致，两者不能相互替代。
重试应保持可追踪
分块失败后只重传缺失部分，能够节省时间，但客户端要保留失败区间、重试次数和最终合并结果。若每次重试都生成新文件名，接收端容易留下多个难以区分的副本。
交付结束时应明确哪个版本进入分析、哪些副本可以清理，以及旧任务如何回退。这样换设备或更换区域节点时，团队不会重新猜测文件来源。