用find + sha256sum可递归生成整个目录树的校验清单：find /path/to/dir -type f ! -size 0 -print0 | xargs -0 sha256sum 2>/dev/null | sort > checksums.sha256；验证时需确保路径一致、换行符规范（如用dos2unix处理）、模式统一（推荐带星号的二进制格式），并可用sha256sum -c -w --quiet校验。
用 find + sha256sum 生成并验证整个目录的校验清单
直接跑 sha256sum * 只能处理当前目录一层，子目录里的文件全被忽略。真要覆盖整个目录树，必须用 find 配合 -exec 或 xargs。推荐优先用 find ... -print0 | xargs -0 sha256sum，它比 -exec ... \; 快得多，尤其在几千个文件时差异明显。
生成校验文件的标准命令是：
find /path/to/dir -type f ! -size 0 -print0 | xargs -0 sha256sum 2>/dev/null | sort > checksums.sha256
说明：
-
-type f排除目录、符号链接、设备文件，避免sha256sum报错中断 -
! -size 0跳过空文件（它们都生成相同哈希，干扰重复检测） -
-print0和-0组合处理含空格、换行、中文的路径，不加这个，路径里有空格就直接失败 -
2>/dev/null屏蔽权限拒绝（如/proc下的文件）等错误，不让管道断掉 -
sort让输出按哈希值排序，方便后续人工扫或脚本处理
校验时为什么总报 FAILED 而不是 OK
运行 sha256sum -c checksums.sha256 却大量报 FAILED，大概率不是哈希算错了，而是路径或格式对不上。最常踩的坑有三个：
- 校验文件里存的是相对路径（比如
./data/config.json），但你不在原来生成它的目录下执行-c，sha256sum就找不到文件 - 校验文件是 Windows 下生成的（CRLF 换行符），Linux 的
-c会把换行符当成文件名一部分，导致解析失败；先用dos2unix checksums.sha256 - 原始校验行用了星号格式（
a948... *config.json），表示二进制模式；但你当前系统默认文本模式读取，就会因换行符归一化导致不一致——统一用带星号的格式最稳妥
调试建议加 -w（警告非法格式）和 --quiet（只输出失败项）：sha256sum -c -w --quiet checksums.sha256。
md5sum 还能不能用？什么时候该换 sha256sum
能用，但仅限非安全场景：比如内部备份校验、确认大文件是否传完整、排查磁盘静默损坏。MD5 碰撞已被实证（两份不同内容可产出相同 MD5），所以任何涉及防篡改、可信分发、签名绑定的场合，必须换 sha256sum。
二者命令行为几乎完全一致，替换成本极低：
- 生成：把上面命令里的
sha256sum换成md5sum即可 - 校验：同样换命令名，输出格式、
-c逻辑、退出码都一样 - 性能上，MD5 确实快 10–20%，但现代 CPU 几乎感知不到；而 sha256 的抗碰撞强度是 MD5 的指数级提升
如果你的校验清单要存半年以上、或供他人复用，别省这点时间，直接上 sha256sum。
cksum 能不能替代？适合什么场景
可以，但目的完全不同：cksum 不是密码学哈希，它是 CRC32 校验，设计目标是快速发现传输或存储中的**意外损坏**（比如内存故障、坏扇区、网卡丢包），而不是防人为篡改。
它的优势是快——比 md5sum 快 3–5 倍，特别适合超大文件（几百 GB 日志、镜像）或高吞吐批量扫描。但弱点也很明确：
- 完全不抗碰撞：改两个字节就可能恢复原 CRC 值，无法用于可信验证
- 输出只有十进制数字（如
3124567890 123456789 /path/file），和主流校验文件格式不兼容 -
cksum -c不存在，没法像sha256sum -c那样一键回验
结论：日常完整性巡检、运维脚本中查“文件坏了没”，用 cksum；要生成可交换、可审计、防篡改的校验依据，必须用 sha256sum。
