cat按命令行顺序拼接，非文件名序；通配符展开不可靠；大文件合并需预估空间并避免同分区写入；编码/二进制混用致乱码；去重过滤等逻辑不应依赖cat，应明确合并目的。
cat 合并文件时顺序错乱怎么办
默认按命令行给出的顺序拼接，不是按文件名数字或字母序。比如 cat file1.txt file10.txt file2.txt 会先输出 file1.txt，再是 file10.txt（因为字符串比较中 "10" "2"），最后才是 file2.txt，内容就乱了。
常见错误现象：合并日志或分片数据后发现时间线跳变、编号不连续。
- 用
ls -v | xargs cat（-v支持自然排序，对file1file10file2正确排序） - 明确指定顺序：
cat file1.txt file2.txt file3.txt > merged.txt，别依赖 shell 展开逻辑 - 避免通配符盲目使用：
cat file*.txt的实际顺序取决于 shell glob 结果，不可靠
合并大文件时磁盘爆满或卡死
cat 本身不缓存，但重定向写入时若目标文件在同一分区，且源文件总大小接近剩余空间，可能在写到一半时失败，而部分输出已写入，导致脏数据。
使用场景：合并多个 GB 级日志或数据库导出分卷（如 data_part_001.sql ~ data_part_100.sql）。
- 提前检查空间：
du -sh file*.sql | awk '{s+=$1} END {print s}'粗略估算（注意单位，du -h输出不能直接算） - 优先用
cat file1.sql file2.sql > /tmp/merged.sql，把输出放不同磁盘分区 - 不要用
cat file*.sql >> merged.sql追加——每次打开文件都涉及 inode 操作，小文件多时开销明显
二进制文件或编码不一致的文本合并后乱码/损坏
cat 是字节级拼接，不识别编码、不校验格式。UTF-8 文件混入 GBK 或带 BOM 的文件，或 PNG/JPEG 等二进制文件被当文本处理，结果不可逆。
典型错误：把几个 .csv（有的 Excel 导出带 BOM，有的 Python pandas 生成无 BOM）直接 cat，后续 awk 或 python csv 解析失败。
- 先统一编码：
iconv -f gbk -t utf-8 file_gbk.csv > file_utf8.csv，再拼接 - 确认是否为纯文本：
file -i *.csv查看charset字段 - 二进制文件慎用
cat拼接——除非你清楚格式规范（如 tar 分卷必须用cat part1.tar part2.tar > full.tar，这是 tar 协议允许的）
需要去重、过滤或按条件合并时别硬刚 cat
cat 只负责拼接，没有逻辑能力。强行用 cat a b c | sort -u 或 cat *.log | grep "ERROR" 看似可行，但掩盖了真实需求边界：拼接是前置步骤，还是整个流程一环？
容易踩的坑：日志合并后才 grep，丢失了上下文（比如 ERROR 前后的 INFO 行）；或 sort 改变了原始时间顺序。
- 如果只要筛选后的内容，直接
grep "ERROR" *.log > errors.log，绕过拼接 - 如果必须保留原始块结构（如每个文件代表一个服务实例），先拼接再处理，但加注释标记来源：
for f in *.log; do echo "=== $f ==="; cat "$f"; done > all.log - 去重且保序？
awk '!seen[$0]++' all.log比sort -u更安全
真正麻烦的从来不是拼接动作本身，而是没想清楚“合并”到底要达成什么效果——是物理连接、逻辑聚合，还是为下一步处理铺路。动手前花三十秒确认这点，比查五次 man cat 省事。
