提到 Linux 下的文件完整性检查网上十篇教程有八篇在讲 md5sum 和 sha256sum真正愿意把 cksum 讲明白的文章反而不多。这其实有点可惜cksum 是 POSIX 标准命令代码量小、零依赖几乎任何一台 Linux 机器上都有最小化安装的容器里都能找到它的身影。我年前帮同事排查一个 3GB 安装包解压报错的问题下载工具显示任务完成可解压到一半就报 CRC 错误最后就是用 cksum 前后一对比发现文件在下载过程中被截断了。从那以后我的习惯就变了碰到大文件传输、U 盘拷贝、备份归档这类场景先顺手跑一遍 cksum 记录下校验值和字节数后面再做对照。这篇笔记我打算按自己的使用逻辑来写先说清楚 cksum 能解决什么问题、输出里的三个字段分别是什么意思再做几个可以直接照着敲的实例然后是踩过坑之后总结出来的排错思路最后把 cksum 和 md5sum、sha256sum 的选型差异以及一堆注意事项拉成清单。无论你是刚开始学 Linux 的新手还是天天跟服务器打交道的运维这篇应该都能给你省点时间。1. 为什么你需要一个“冷门”但系统自带的校验命令1.1 一次让我印象深刻的解压事故先说说开头提到的那件事。同事从内网服务器拉了一个离线安装包3GB 左右下载工具显示进度 100%。但解压到一半终端直接刷出一屏 CRC 错误压缩包整个作废。重新下载一次不仅耗时还不能确定问题到底出在网络传输、磁盘写入还是源文件本身。当时我的处理方式很朴素先到源服务器上对原始文件跑一条cksum把校验值和字节数记下来再到同事机器上跑同样的命令。两个值一对字节数差了大概几百 KB说明文件根本没传完整下载工具显示的 100% 并不可靠。这个结论一分钟内就出来了比重新下载快得多也比讨论“为什么下载工具会误报”更有意义。这个案例想说明一个点文件完整性检查不是你觉得自己文件坏了才要去做的事而应该在下载、拷贝、归档这些操作之前就留下一个“基准值”。cksum 就是用来生成这个基准值的最轻量工具。1.2 完整性检查的三层威胁模型我在实际工作里习惯把“文件完整性”拆成三个层次因为不同层次的威胁决定了你要用哪个工具。第一层是传输或存储过程中的偶然损坏。网络丢包、磁盘坏道、内存位翻转、U 盘老化这些都会让文件里的某些字节变了。这是最常见的情况也是 cksum 最适合处理的层次。第二层是误操作导致的内容变化比如编辑配置文件时手滑多打了个空格或者脚本意外覆盖了文件。这类问题也能被 cksum 发现因为任何一字节的变化都会反映在 CRC 校验值上。第三层是恶意篡改有人故意修改文件内容甚至伪造校验值来掩盖痕迹。这一层 cksum 就力不从心了。为什么因为 cksum 默认用的 CRC 校验值只有 32 位它的设计目标是检测随机错误而不是对抗有意的碰撞构造。一个懂技术的人完全可以构造出两个内容不同但 CRC 相同的文件。所以如果场景涉及安全、审计、防篡改应该用 SHA-256 这一类加密哈希工具而不是 cksum。这个边界必须先搞清楚否则容易把 cksum 用错地方。1.3 cksum 的生存现状老、稳定、到处都有cksum 是很老的命令很早就进入了 POSIX 标准这意味着所有遵循 POSIX 的 Unix 系统都有它。Linux、macOS、各种 BSD、Solaris 这些系统上你都能直接敲cksum不需要安装任何东西。在内网环境、离线服务器、最小化容器镜像里这个优势会被放大到极致——你甚至可能没有 md5sum但大概率有这个命令。另外还有一个很多人没注意到的点处理大文件时cksum 的默认 CRC 算法计算量小速度通常比 sha256sum 快不少。现代 x86 CPU 基本都有 CRC32 指令做这种计算属于“硬件级操作”。如果你只是想知道“文件拷过去坏没坏”完全没必要动用 SHA-256 这样的重型武器杀鸡用牛刀。2. 搞懂输出和算法三个字段、两种 CRC、一个 -a 参数2.1 三个字段到底代表什么cksum最基础的用法就是后面跟文件名不加任何参数。命令跑完之后终端会输出一行内容里面用空格分成三个部分$ cksum install.iso 校验值 字节数 文件名第一列是 CRC 校验值一个十进制整数范围在 0 到 4294967295 之间。它本质上是把文件内容当作一大串数据通过特定的多项式计算出来的“指纹”。第二列是文件的字节数这个字段很容易被人忽略但它是 POSIX 标准特意保留的。第三列是文件名如果你从标准输入读取数据这一列会显示为-。我特别想强调第二列的意义。CRC 校验值只有 32 位碰撞概率大约是 43 亿分之一。虽然这个概率已经很低但在传输超大文件或者做批处理时多一层字节数判断就多一分把握。就算 CRC 理论上撞了字节数不一样也能立刻发现问题。这就是为什么 cksum 输出里包含字节数而不是像 md5sum 那样只输出哈希和文件名。2.2 默认的 POSIX CRC-32和 gzip、zip 的 CRC-32 不是一回事这是 cksum 最容易被误解的地方。你可能会在某个压缩包的说明里看到“CRC32: 9C0F43E1”这样的十六进制值然后在 Linux 上跑cksum 文件名发现对不上。请记住一条结论cksum 使用的 CRC 算法遵循 POSIX 标准和 zlib 里那套被 gzip、zip、png 等大量软件使用的 CRC-32 并不是同一个东西两者在初始值、位处理方式、结果后处理等细节上有差异。所以在实际使用中不要拿 cksum 的结果去跟 unzip 输出的 CRC 值、或者 Windows 下某些压缩软件显示的 CRC32 做比对它们算法不同没有可比性。这不算 cksum 的缺陷只是它归属于另一个标准体系。你只需要保证“生成基准值”和“验证值”用的是同一个工具、同一套算法就不会有问题。2.3 -a 参数同一个命令还能算 md5、sha256GNU coreutils 8.6 之后cksum提供了一个容易被忽视的选项-a或--algorithm可以指定算法。支持的算法包括crc、md5、sha1、sha224、sha256、sha384、sha512更新版本还能选sm3、blake2b。比如你想快速算一个文件的 SHA-256 值可以直接$ cksum -a sha256 config.yml输出内容和 sha256sum 的结果本质上是同一个摘要只是格式上略有差异。这个参数在某些特殊环境里很实用当你的脚本已经大量使用cksum又不想额外引入sha256sum的依赖时可以用-a来统一入口。但这里有一个必须注意的坑BusyBox 和老版本的 coreutils 里cksum不一定支持-a。我的建议是在跨环境脚本里不要默认依赖这个特性优先用最基础的默认 CRC 模式。3. 从单文件到批处理最常用的几个实例拆解3.1 最基础用法直接给文件算值先创建一个测试文件我习惯用echo生成一个小文件来验证命令行为$ echo hello cksum demo.txt $ wc -c demo.txt 12 demo.txt然后跑cksum$ cksum demo.txt 校验值 12 demo.txt输出里的第二列正好是 12和wc -c看到的字节数一致。这说明 cksum 是按字节处理内容的不会因为文本文件或二进制文件而改变行为。你可以拿/dev/null试一下会得到0 0 /dev/null零字节文件的校验值就是 0。这个特性在脚本里可以用来快速判断一个文件是不是空文件。3.2 读取标准输入管道场景下的校验cksum不接文件名时会从标准输入读取内容。最常见的用法是配合管道$ echo hello cksum | cksum 校验值 12 -注意第三列是-表示数据来源是标准输入。这个能力在归档场景里很好用。比如你想给一个目录的内容整体做个校验而不是逐个文件去算可以先把目录打成 tar 流再送进 cksum$ tar cf - /var/log | cksum这样你得到的是整个目录内容对应的“流级”校验值。归档前后各跑一次只要两个值一致就能断定目录内容没有发生变化。这个思路比遍历几百个文件逐个比对高效得多。3.3 一次校验多个文件cksum后面可以跟多个文件结果是一行一个文件$ cksum demo.txt /etc/hosts /etc/passwd 校验值 12 demo.txt 校验值 198 /etc/hosts 校验值 1723 /etc/passwd批量输出的顺序和你在命令行里的书写顺序一致。这个特性可以配合通配符使用$ cksum *.log *.tar.gz如果你需要把结果保存下来直接重定向到文件里$ cksum *.log *.tar.gz CHECKSUMS.cksum这个文件就相当于一个“校验清单”后面我会专门写怎么用它做验证。3.4 文件内容变化后校验值的变化很多人对校验值不敏感是因为没见过实际变化。做个很直观的测试$ echo hello a.txt $ cksum a.txt 校验值A 6 a.txt然后给文件加一个词再试$ echo hello world a.txt $ cksum a.txt 校验值B 12 a.txt内容从 6 字节变成 12 字节CRC 校验值完全变了。这里我顺便提醒一个容易踩的细节echo默认会在行尾加一个换行符所以echo hello写进文件的实际是hello\n这 6 个字节。如果你用echo -n hello a.txt文件只会是 5 个字节校验值当然也不同。文件末尾多一个换行符都会导致校验值变化这在对比两端文件时很重要。4. 排错实录两边算出的 cksum 值不一致问题出在哪4.1 第一步先看字节数再看 CRC当你拿着源文件的校验值去对比另一台机器上的拷贝发现两边对不上时先别急着怀疑 CRC 算法。我的排查顺序非常固定先看输出的第二列字节数。字节数都不一样那就说明文件长度都变了内容必然有差异可以直接放弃“CRC 碰撞导致误判”这种小概率幻想。如果字节数一样但 CRC 值不同说明文件总长度没变但中间某些字节内容被改了。这个时候我会用cmp做逐字节对比$ cmp -l file1 file2cmp -l会列出第一个不同字节的位置和具体数值。如果它没有任何输出说明两个文件内容完全相同。如果它报错退出就说明存在差异。这个工具在排查时特别高效因为它能直接告诉你差异发生在文件的哪个位置。4.2 跨平台传输的换行符陷阱最容易导致字节数对不上但截图不明显的问题就是换行符差异。Windows 文本文件的换行是CRLF两个字节Linux 和 macOS 是LF一个字节。如果你用 FTP 的 ASCII 模式传文本文件FTP 会自作主张把换行符转成目标系统的格式结果就是文件长度变了cksum 必然对不上。我遇到过的情况是一个配置文件从 Windows 机器传到 Linux 服务器两边字节数差了 20 多个用hexdump一看每隔几行就多出0d 0a也就是 CRLF。当时处理办法也很简单用 FTP 的 binary 模式重新传或者传完之后用dos2unix把换行符统一回来。这个问题在 Windows 和 Linux 之间互相传文件时特别常见排查 cksum 不一致的时候一定要把这个因素考虑进去。4.3 哪些东西改了不影响校验值和直觉相反有几种改动不会影响 cksum 的结果第一修改文件权限。chmod只是改了 inode 里的元数据文件内容没有变cksum 值不变。第二修改文件的所有者和所属组。同样属于元数据不影响内容指纹。第三重命名文件或移动文件路径。cksum 只读内容不关心文件名。第四修改文件的时间戳。touch改变的是 atime、mtime 这类时间信息不影响内容。所以在排查时如果两边 cksum 对不上不要去想“是不是有人改了权限”先从内容层面找原因。反过来如果你改了权限后发现 cksum 值变了那一定是文件内容在某个环节被悄悄动过而不是权限本身引起的。这里还要提一个软链接的问题。cksum在遇到软链接时默认会跟随链接去读取最终目标文件的内容所以算出来的结果是目标文件的指纹而不是链接本身。如果目标文件不存在会直接报No such file or directory。这一点在一些打包场景里容易被误解有人以为软链接的校验值应该指向“链接文本”不是这样的。4.4 生成或传输过程的隐性损坏如果上面这些常规原因都排除了两边字节数一致但 CRC 还是不同那就要考虑更底层的因素了。比如文件在生成过程中被并发写入。我曾经在一台服务器上看到一个日志文件在滚动归档时被压缩进程同时读取导致归档包里的内容和源内容对不上。遇到这种场景正确的做法是先确保文件处于“静止状态”再生成基准值。另外磁盘坏道也可能导致读取结果不稳定。一个文件第一次读出来是 A 值第二次读出来变成 B 值这两次 cksum 不一样那就说明存储介质本身出问题了。此时不要再反复重跑 cksum赶紧备份能读出来的数据然后检查磁盘健康状态。cksum 在这里扮演的角色不是证明文件“好”而是第一个跳出来告诉你“坏了”这就是它的价值。5. cksum、md5sum、sha256sum 怎么选一张表说清楚5.1 三者的核心差异很多初学者分不清这三个工具以为都是算校验和随便用哪个都行。但它们的定位和适用场景差异很明显我把核心区别整理成了一张表对比维度cksummd5sumsha256sum计算算法POSIX CRC-32MD5SHA-256输出内容CRC值 字节数 文件名哈希值 文件名哈希值 文件名是否包含字节数包含不包含不包含抗碰撞能力32位可被刻意构造已发现实际碰撞不适合安全场景当前安全POSIX 可移植性几乎所有 Unix 系统自带GNU 系为主非所有 UnixGNU 系为主非所有 Unix典型用途快速校验传输、拷贝是否损坏一般完整性校验软件发布、安全校验、防篡改很明显cksum 最大的价值在“快速”和“可移植”但也有明显的短板不能用于对抗恶意篡改。MD5 曾经是完整性校验的主流但现在已经能在可接受的时间内构造碰撞所以官方的安全校验清单基本都改用 SHA-256 了。sha256sum 是目前最稳妥的安全校验工具缺点是在没有硬件加速的老机器上算大文件时会比较慢。5.2 我对选型的一点实际建议我的选择原则很简单就一句话看你要防的是“意外损坏”还是“恶意篡改”。只是担心文件在传输或拷贝过程中损坏比如从服务器下载大文件、往 U 盘里拷资料、做备份归档用 cksum 就够了速度快命令简单任何环境都能用。如果是下载官方发布的 Linux 内核、软件安装包这些场景官方通常会给出 SHA-256 校验值这时候直接用 sha256sum 去和官方值比对不要用 cksum。如果你需要长期存档并防止有人刻意篡改文件也必须用 sha256sum 或更强的算法。还有一种混合用法我在生产环境里经常用发布软件时同时生成两份校验文件一份是 cksum 清单负责日常快速核验一份是 sha256sum 清单负责安全审计。日常用前者出问题或做安全合规时用后者两不耽误。6. 把 cksum 用进日常两个可以直接抄的校验脚本6.1 生成校验清单单个文件校验很容易但碰到几十个文件、几百个文件时手工一个个看输出太累。最实用的做法是把校验结果保存成清单文件。比如在一个包含多个压缩包的目录里$ cd /data/backup $ cksum *.zip *.tar.gz CHECKSUMS.cksum生成出来的CHECKSUMS.cksum每一行都是“CRC值 字节数 文件名”这就是后面校验的依据。这里有一个我踩过的坑生成清单前确认一下当前目录下没有名为CHECKSUMS.cksum的旧文件否则cksum *.zip *.tar.gz不会把清单本身算进去问题不大但如果你的通配符是cksum *清单文件本身也会被算进去下一次校验时清单内容变了会引发一串莫名其妙的 FAIL。6.2 根据清单批量验证生成清单之后校验的操作我通常用一个 bash 脚本完成逻辑很直接逐行读取清单对每个文件重新算一次 cksum再和清单里的值比对。#!/usr/bin/env bash # 用法: ./check_cksum.sh CHECKSUMS.cksum while read -r sum bytes file; do if [ ! -f $file ]; then echo MISS: $file continue fi actual$(cksum $file | awk {print $1, $2}) if [ $actual $sum $bytes ]; then echo OK: $file else echo FAIL: $file fi done $1这个脚本有个巧妙的地方read -r sum bytes file会把文件名部分剩余的所有内容都塞进file变量。所以即使文件名里包含空格只要空格不在文件名的开头或结尾也能正确处理。验证时awk {print $1, $2}拿到的正好是当前文件的 CRC 和字节数然后和清单里的两个字段比较两个都一致才输出 OK。实际跑一遍你会看到类似这样的输出$ ./check_cksum.sh CHECKSUMS.cksum OK: release-1.0.tar.gz OK: release-1.0.zip FAIL: debug-notes.txt MISS: old-package.tar.gzFAIL 说明文件内容变了MISS 说明文件直接不存在。这两类情况分别处理就行。6.3 文件名包含空格、CRLF 换行这些边界情况脚本虽然简单但边界情况还是要说清楚。如果文件名以空格开头或结尾上面的read默认会把分隔符吃掉导致file变量里的路径缺了空格校验直接报 MISS。更极端的场景是文件名里包含换行符这在 Linux 下是合法的但任何“按行解析”的清单方案都会在这类文件上翻车。针对这类场景我的建议是在日常归档时统一规范文件名避免空格开头结尾也避免换行符。如果确实要处理特殊文件名可以通过find ... -print0配合xargs -0来规避换行问题但那套逻辑对普通用户来说太重了不如先把文件名规范化来得省心。还有一个和 Windows 相关的坑如果你在 Windows 上用记事本编辑过CHECKSUMS.cksum保存的换行符是 CRLF在 Linux 上用read读取时最后一列文件名后面会粘一个\r导致文件找不到。解决办法很简单先跑一次dos2unix CHECKSUMS.cksum或者用sed -i s/\r$// CHECKSUMS.cksum把回车符去掉。7. cksum 注意事项清单建议收藏版7.1 三条最容易被忽视的规则第一条别拿 cksum 当安全工具。前面反复提过CRC 是检错码不是加密哈希。只要有预谋的攻击者构造一个 CRC 相同的文件并不是难事。所以但凡涉及“防篡改”的场景请转向 sha256sum。第二条不要拿 cksum 的 CRC 值和压缩软件显示的 CRC32 做比对。两种 CRC 算法不同结果不可互换。如果你需要跟 zip 包里的 CRC 核对应该用unzip -v这样的工具或者用 Python 的zlib.crc32而不是 cksum。第三条别对正在被写入的文件跑 cksum。日志文件、数据库文件、正在下载的临时文件内容每时每刻都在变化第一次和第二次跑出来的值可能不一样很容易造成误判。生成基准值的正确时机是文件已经确定不再变化之后。所以我的习惯是先拷贝或下载到一个临时目录确认任务彻底结束后再校验。7.2 性能与适用边界的补充cksum 默认的 CRC 模式消耗的资源很少但也不是完全没有开销。对一个 10GB 级别的大文件做校验耗时主要取决于磁盘读取速度其次才是 CPU 计算。在老的机械硬盘上跑瓶颈是 I/O在 NVMe SSD 上跑几十秒内就能跑完一个大文件。如果是在交叉编译的嵌入式环境里或者目标系统只有 BusyBox你可能会发现cksum默认能跑但-a sha256报不支持。这个兼容性差异在写部署脚本时要格外注意。我的做法是做一个能力检测先跑cksum --help看看有没有-a没有就用默认模式避免脚本在不同环境里行为不一致。还有一个常见的操作误区对目录直接跑 cksum 会报错。比如cksum /etc会得到Is a directory的提示。想对目录做整体校验要么用 tar 流打包后校验要么先find递归出文件列表再逐个处理。直接对着目录跑是行不通的。7.3 什么场景下我会绕过 cksum如果是比较两台服务器上的同一个文件是否一致而且两台机器都能登录直接用cmp比 cksum 更直接不需要先取基准值。cksum的独特优势在于“离线对比”只需要一份历史校验值不需要源文件在场。比如你只有笔记本上的文件却知道服务器上同一文件的 cksum 值就能判断两边是否一致。如果是做软件发布的安全校验官方给了 SHA-256 值那么无论 cksum 多快多方便我都会用 sha256sum 去对数。这不仅是习惯问题也是安全边界问题。CRC 只负责检测“意外”不负责对抗“蓄意”。如果是做长期归档我更倾向于同时记录 cksum 和 sha256sum 两份结果。cksum 用于平时抽查存储介质是否老化sha256sum 用于未来某一天需要跟外部审计方证明文件完整性时使用。日常轻量核对跑 cksum 就够了重武器留在真正需要的时候。这个工具写进脚本、写进工作流之后最大的感受是省心。以前每次传完大文件总有种“到底成没成”的不确定感现在多敲一条命令、多留一个清单心里就有底。Linux 下类似的命令还有不少像 cksum 这样看起来不起眼、真到用时才觉得值得学好的大概就是这类系统自带小工具的朴素价值。