Linux用cat合并多个文件技巧

Linux 中用 cat 合并文件看似简单，实则暗藏诸多陷阱：命令行顺序决定拼接结果而非文件名自然序，盲目使用通配符易致内容错乱；大文件合并需警惕磁盘空间不足和同分区写入引发的脏数据风险；编码混杂或二进制文件直接拼接将导致乱码或损坏；而依赖 cat 实现去重、过滤等逻辑更会掩盖真实需求，破坏时间序或上下文。真正关键的不是“如何用 cat”，而是先厘清合并目的——是物理串联、结构化聚合，还是为后续处理铺路？一次审慎的设计，远胜反复调试错误输出。

cat 合并文件时顺序错乱怎么办

默认按命令行给出的顺序拼接，不是按文件名数字或字母序。比如 cat file1.txt file10.txt file2.txt 会先输出 file1.txt，再是 file10.txt（因为字符串比较中 "10" "2"），最后才是 file2.txt，内容就乱了。

常见错误现象：合并日志或分片数据后发现时间线跳变、编号不连续。

• 用 ls -v | xargs cat（-v 支持自然排序，对 file1 file10 file2 正确排序）
• 明确指定顺序：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 省事。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Linux用cat合并多个文件技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。