Linux用split和cat合并分割大文件需注意：split必须用-b指定字节单位（如-b 500M）避免破坏二进制结构；分片命名须自然排序或显式sort；合并后须用file、unzip -t及sha256sum校验完整性。
Linux 合并和分割大文件，不用额外工具，split 和 cat 就够用——但参数选错、路径没写全、顺序搞反，结果就是文件损坏或拼不回来。
用 split 按大小切分大文件，别只记 -b
默认行为是按行切（每 1000 行一个文件），对二进制文件（如 ISO、压缩包）会直接破坏结构。必须显式指定字节单位：
-
split -b 500M bigfile.zip part_：切成每个 500MB 的文件，前缀为part_，生成part_aa、part_ab等 -
split -b 1G --numeric-suffixes=1 bigfile.img img_：用数字后缀（img_1、img_2），更易排序，适合脚本处理 - 别用
-l处理非文本文件；-b值后面必须带单位（K/M/G），写成split -b 500000000易出错且难读 - 切完检查：
ls -lh part_*看大小是否符合预期，head -c 32 part_aa | xxd确认开头没被截断
用 cat 合并时，顺序错一个就全废
cat 不校验内容，只是线性拼接。如果文件名乱序、漏掉某个分片，合并结果不可用（尤其 ZIP、PDF、磁盘镜像）：
- 确保分片命名可自然排序：
part_aapart_ab part_ac；若用了--numeric-suffixes，就用img_{1..12}这种 shell 展开，别手输 - 安全写法：
cat part_* > restored.zip（前提是part_*按字母序正好对应切割顺序） - 更稳妥：
printf '%s\n' part_* | sort | xargs cat > restored.zip，强制按字典序排 - 合并后立刻验证：
file restored.zip看类型是否识别正常；unzip -t restored.zip测试 ZIP 完整性
跨机器传输后合并失败？先查换行符和文件结尾
Windows 传过来的分片可能被编辑器加了 \r\n，或 FTP 以 ASCII 模式传输导致二进制损坏：
- 用
file part_aa确认每个分片仍是“data”类型，不是“C source”或“text” - 对比原始文件和第一个分片头：
head -c 16 bigfile.zip | xxd和head -c 16 part_aa | xxd，必须一致 - 用
sha256sum核对原始文件和合并后文件的哈希值（提前算好！）：sha256sum bigfile.zipvssha256sum restored.zip - FTP 传分片务必设为 binary 模式；SCP 或 rsync 更可靠
真正麻烦的不是命令本身，而是分片命名规则、传输完整性、合并时的排序逻辑这三处——少检查任何一环，合出来的文件大概率打不开。
