split 默认按1000行切割且不校验换行合法性，遇超长行、空字节或UTF-8截断会破坏数据；应显式用-l（行数）或-b加--line-buffered（大小）切割，并验证边界完整性。
split 默认按行切割不靠谱，超大文件必须加 -l 或 -b 显式指定；不加参数时它会按 1000 行切，但遇到二进制内容或换行符异常的文件极易出错。
为什么直接用 split file.txt 常常切坏文件
Linux 的 split 默认行为是按行数切（1000 行/块），但它不校验每行是否合法——遇到没有换行符的超长行、空字节 \0、或 UTF-8 多字节截断时，会把一行硬生生劈开，后续用 awk 或 sed 处理就直接报错或丢数据。
- 常见错误现象：
split: file.txt: input line too long或切完后某块末尾缺半个中文、JSON 格式损坏 - 真实场景：日志归档、数据库导出的
.sql、网络抓包的textdump文件 - 正确做法：永远显式指定切割依据，不依赖默认值
按固定行数切：用 -l，但要注意最后一块可能太小
适合结构化文本（如 CSV、Nginx 日志），前提是每行完整且无嵌套换行。
- 切每 50000 行为一块：
split -l 50000 access.log access_part_ - 加
-d用数字后缀（而非字母）：split -l 50000 -d access.log part_→part_00,part_01 - 加
--additional-suffix=.log统一后缀：split -l 50000 -d --additional-suffix=.log access.log part_ - 性能影响：纯顺序读，内存占用低；但若某行远超平均长度（比如单行 10MB），仍可能触发内核缓冲区警告
按文件大小切：用 -b，必须配合 --line-buffered 防止截断行
适合不确定行长度的原始数据，但 split -b 默认“字节级硬切”，会破坏行边界。解决方法只有两个：
- 用
--line-buffered（GNU coreutils ≥ 9.0）：split -b 100M --line-buffered huge.json json_—— 它会找到最近的换行符再切 - 旧系统没这个选项？改用
awk流式处理：awk -v n=1000000 'NR%n==1{x="part_"++i;}{print > x}' huge.csv（按行号模切，不依赖文件大小） - 注意单位：
-b 2G支持K/M/G，但split -b 100MB是错的，必须写100M
验证切割结果是否可用，别只看 ls -lh
切完立刻检查首尾几行，尤其关注跨块边界处：
- 看前一块结尾：
tail -n 3 part_05 - 看后一块开头：
head -n 3 part_06 - 确认是否完整：用
wc -l累加所有块行数，对比原文件wc -l file.txt；差值 ≠ 0 就说明有行被截断或漏读 - 容易被忽略的点：某些日志文件末尾没换行符，
split -l会把最后一行单独塞进新块，但cat拼回去时可能少个换行，导致下一行粘连
