刚好我手上有一个Unity安装包, 就发给他了。
不知道啥原因，他说传输后打不开？
怎么可能呢？
接着，再传了一次还是打不开。
这让学委一下子想到了：得cksum一下
1） 先cksum工具本地算一次，得到校验码
2）然后在接受的系统中又计算一次，得到文件校验码
3）当两个数字校验相等，文件被认为是被正确传输了
使用就像下面一样：
cksum 文件名
第一个数字：2283207869 //为校验码
第二个数字： 844948304 // 为文件字节数
然后我让小白在本机跑一边cksum，发结果给我，一看他那边的校验数字居然是 33303330333 ，这个数字，稍微思考一下就很离谱！
很明显Unity包传输出错了。
这次我直接拷贝U盘给他了，并且进入U盘对应目录进行cksum了，万无一失！
好了，小白可以先走了。亲爱的读者我们继续学习一下cksum吧，很多使用的。
cksum官方补充
Linux cksum命令用于检查文件的CRC是否正确。确保文件从一个系统传输到另一个系统的过程中不被损坏。
CRC是一种排错检查方式，该演算法的标准由CCITT所指定，至少可检测到99.998%的已知错误。指定文件交由cksum演算，它会回报计算结果，供用户核对文件是否正确无误。
https://www.man7.org/linux/man-pages/man1/cksum.1.html
这个算法不继续介绍，本文谈谈应用。
更多应用 - sha512cksum
sha512cksum 比cksum（32位 cksum）更加可靠，因为是512位哈希cksum。
比如我们常见的maven（Java项目管理工具）：
下图的表格第二列为下载链接，第三列为每一个包的sha512cksum的签名。
上面页面的链接可以点击【maven下载页面】
我们可以通过点击上面的链接下载，比如这个：maven tar gz包
通过这个链接下载然后跑shasum在本地校验一次。
shasum -a 512 apache-maven-3.8.1-bin.tar.gz #得到这个签名：0ec48eb515d93f8515d4abe465570dfded6fa13a3ceb9aab8031428442d9912ec20f066b2afbf56964ffe1ceb56f80321b50db73cf77a0e2445ad0211fb8e38d
这个值跟第三列链接的文件【点这里下载sha512】内容必须一致.
操作复杂，学委准备了下面的脚本。
#!/bin/sh #雷学委的demo代码 #仅支持macbook url=https://mirror-hk.koddos.net/apache/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.tar.gz #url_sha512=${url}.sha512 url_sha512=https://downloads.apache.org/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.tar.gz.sha512 curl ${url_sha512} -o maven.tar.gz.sha512 curl ${url} -o maven.tar.gz shasum -a 512 maven.tar.gz
读者可以运行这个脚本试试，最好的验证效果如下图：
更多场景
多文件迁移校验
通常是用在大量的打包数据迁移，生成每个文件的数字签名。
部署制品的校验
做Java的同学知道一个叫做Nexus的依赖仓库，不止可以放jar，还能放tgz包，我们通常会生成tgz包的同时，进行sha512把签名结果存到文件一并传到nexus上面。
当我们拿tgz文件部署的时候，同时下载tgz和sha512，本地校验，保证了部署安装的包跟实际交付的一致。
