cat合并文件时出现空行是因POSIX要求文件以换行符结尾，末尾的\n被保留；若某文件无结尾换行，则与下一文件首行连在一起。重定向用>会覆盖原文件，需用临时文件替换或写入新名。
用 cat 合并文件时，为什么新文件里多出空行？
常见现象是执行 cat file1.txt file2.txt > merged.txt 后，merged.txt 开头或结尾有意外空行。这通常不是 cat 的问题，而是源文件本身以换行符结尾（POSIX 要求），而最后一个文件末尾的换行被当成“内容的一部分”保留下来——看起来像多余空行，其实是标准行为。
真正要注意的是：如果某个文件不以换行符结尾（比如用 echo -n "hello" > broken.txt 生成），cat 会把它和下一个文件首行连在一起，导致格式错乱。
- 检查文件是否规范结尾：
hexdump -C file.txt | tail，末尾应为0a（即\n） - 强制补换行：
printf '\n' >> file.txt（仅对无结尾换行的文件） - 避免手动拼接：不要用
cat a b c > out处理含二进制或非文本内容的文件
合并时想跳过某些文件或按特定顺序读取
cat 本身不支持通配符过滤或排序，它只是按命令行给出的顺序依次输出。如果你写 cat *.log，shell 展开顺序取决于文件系统排序（通常是字典序），不可靠。
更可控的做法是显式列出或用 find + xargs 控制顺序：
- 按修改时间升序合并：
find . -name "*.log" -type f -print0 | xargs -0 ls -t | xargs -I{} cat {} - 排除临时文件：
cat $(ls *.log | grep -v '\.swp$')（注意：含空格路径会崩，慎用；推荐用find -not -name "*~"） - 需要去重或筛选内容？别在
cat这层做，后续接sort -u或grep
cat 重定向到已有文件时，为什么原内容全没了？
因为 > 是覆盖写入，不是追加。cat a b > out 会清空 out 再写入，哪怕 out 原本就在参与合并列表里（比如误写成 cat a out b > out），结果一定是空或损坏。
安全做法只有两种：
- 始终写到新文件名：
cat a b c > merged_new.txt - 真要就地更新，先用临时文件再替换：
cat a b c > merged.tmp && mv merged.tmp merged.txt - 用
>>追加时，确认目标文件不参与输入列表，否则会无限循环增长
大文件合并卡住或内存爆掉？不是 cat 的锅
cat 是流式处理，不缓存全文，内存占用恒定。所谓“卡住”，大概率是磁盘 I/O 瓶颈、目标文件系统满、或者重定向目标是管道/设备（如 /dev/stdout 被阻塞）。
排查方向：
- 看磁盘空间：
df -h .，尤其注意/tmp（部分 shell 重定向会经由此） - 检查目标是否可写：
ls -l merged.txt，权限和父目录都得允许写 - 合并超大文件（>10GB）时，避免用
cat加管道再进gzip，改用dd或专用工具如pv监控进度
真正容易被忽略的是：当多个终端同时往同一个文件用 >> 追加，会出现内容交叉错乱——cat 不负责同步，那是应用层该管的事。
