split按字节切分大文件最稳妥，不压缩不解压；应先tar+gzip管道流式输出再split，避免双倍磁盘空间；合并须按字母序cat bigfile_part_{aa..az}，并用sha256sum校验完整性。
split 命令怎么按大小切分大文件
直接用 split 最稳妥，它不依赖压缩逻辑，只做纯字节切割，适合后续手动分发或配合 tar 分卷打包。关键不是“压缩分卷”，而是“先打包再切分”——split 本身不压缩，也不解压。
- 按 100MB 切：
split -b 100M bigfile.tar.gz bigfile_part_（注意后缀下划线不能省，否则生成无后缀文件） -
-b支持K/M/G单位，但别写成100MB（会报错），必须是100M - 默认每块 1000 行，不加
-b容易误切文本文件，导致二进制文件损坏 - 切出来的文件名是
bigfile_part_aa、bigfile_part_ab… 按字母序排列，不是数字序，合并时得靠 shell 展开：cat bigfile_part_* > bigfile.tar.gz
tar + gzip 分卷压缩的正确链式写法
想一步到位“压缩并分卷”，得把 tar 的输出管道给 split，不能先 tar -czf 再切——那样要双倍磁盘空间。管道流式处理才是关键。
- 安全写法：
tar -cf - /path/to/dir | gzip -c | split -b 200M - archive.tgz. - 末尾的
-表示从 stdin 读，archive.tgz.是前缀，切出来是archive.tgz.aa、archive.tgz.ab - 别漏掉
gzip -c的-c，否则gzip会试图写文件，中断管道 - 如果目录含中文或特殊字符，加
--format=posix和-o避免 tar 报 warning（不影响切割，但可能干扰后续解压）
合并后解压失败？检查这三处硬伤
常见报错像 gzip: stdin: not in gzip format 或 tar: Unexpected EOF，基本不是命令写错，而是合并或传输环节出了问题。
- 合并时用了
cat bigfile_part_* > out，但文件顺序错乱（比如 FTP 上传时重命名过），应改用cat bigfile_part_{aa..az} > out显式控制顺序 - 某一块文件被截断（如网络中断传了一半），
ls -l看各块大小是否接近设定值，最后一块小是正常的，但中间块突然变小就可疑 - Windows 下用记事本打开过某块文件再保存——会加 BOM 或换行符，破坏二进制完整性，切忌用图形界面编辑器碰任何
.aa类文件
split 切出来的文件怎么验证完整性
没有内置校验，得自己加一层保障。别依赖文件大小一致，要用哈希比对原始流和合并后流。
- 压缩前先算原数据哈希：
tar -cf - /path/to/dir | sha256sum > original.sha - 分卷后合并再算一次：
cat archive.tgz.* | sha256sum，和original.sha对得上才算真完整 - 如果只是临时分发，加
md5sum更快，但别用于安全场景；sha256sum是底线 -
split不提供校验码生成功能，也别指望tar --tape-length，那玩意儿早废弃了，纯属历史包袱
真正麻烦的是跨平台传输后文件权限或换行符被静默修改，哪怕只差一个字节，gzip 就直接拒绝解压——这点容易被忽略，但修复成本最高。
