Files.copy() 逐个追加写入最稳妥：需显式指定编码、首次写不用APPEND、每文件后写换行符、用try-with-resources关流；混合编码须用BufferedReader逐行转码写入，避免乱码与OOM。
用 Files.copy() 逐个追加写入最稳妥
Java 标准库没有现成的“合并多个文本文件”方法，但用 Files.copy() 配合 StandardOpenOption.APPEND 可靠性高、内存占用低，适合任意大小的文本文件。关键不是“一次性读完再写”，而是流式追加——避免 OOM 和编码错乱。
常见错误是直接用 Files.readAllLines() 读取所有文件再拼接，小文件尚可，一旦某个文件超百 MB 就容易触发 OutOfMemoryError；还有人忽略编码，默认 UTF-8 但源文件是 GBK，结果合并后全是乱码。
- 始终显式指定
Charset，比如StandardCharsets.UTF_8 - 目标文件首次写入不用
APPEND，后续文件才用 - 每追加一个文件后，手动写入换行符（
\n），否则内容会粘连 - 用
try-with-resources确保InputStream正确关闭，别依赖Files.copy()自动关
处理不同编码时必须用 InputStreamReader + BufferedReader
Files.copy() 不支持跨编码转换，如果待合并的文件混用 UTF-8、GBK、ISO-8859-1，直接 copy 会损坏内容。此时必须逐行读取并转码写入。
核心是绕过 Files.lines()（它底层用默认编码），改用带明确 Charset 的 BufferedReader：
立即学习“Java免费学习笔记（深入）”；
try (BufferedReader reader = Files.newBufferedReader(path, charset);
BufferedWriter writer = Files.newBufferedWriter(outputPath, StandardCharsets.UTF_8,
StandardOpenOption.CREATE, StandardOpenOption.APPEND)) {
String line;
while ((line = reader.readLine()) != null) {
writer.write(line);
writer.newLine();
}
}
- 不要用
reader.lines().forEach(writer::write)，这会跳过换行且不兼容 null 行 -
newLine()比硬写"\n"更安全，适配 Windows/Linux 行尾差异 - 若某文件编码未知，可用
juniversalchardet库探测，但需额外引入依赖
命令行参数解析推荐用 Apache Commons CLI
手写 args 解析易出错：路径含空格、选项顺序随意、缺少帮助提示。用 commons-cli 可快速支持 -o output.txt -e UTF-8 file1.txt file2.txt 这类标准用法。
注意两个坑：
-
OptionBuilder已废弃，必须用Option.builder("e").hasArg().argName("charset")... - 非选项参数（即文件路径列表）要用
cmd.getArgList()获取，不是cmd.getArgs() - 输出文件路径若已存在，默认覆盖——加
-f强制或抛FileAlreadyExistsException提示用户
大文件合并时避免 BufferedWriter 频繁刷盘
合并上百个 10MB 文件时，如果每次 write() 后都 flush()，I/O 性能暴跌。但完全不 flush 又怕崩溃丢数据。
折中方案是控制缓冲区大小，并只在换文件或显式需要时 flush：
BufferedWriter writer = Files.newBufferedWriter(outputPath, StandardCharsets.UTF_8,
StandardOpenOption.CREATE, StandardOpenOption.APPEND);
writer = new BufferedWriter(writer, 8192); // 显式设缓冲区为 8KB
- 默认缓冲区是 8192 字节，够用；不必盲目调大到 1MB
- 每个输入文件处理完后调一次
writer.flush()，保证该文件内容落盘 - 不要在循环内每行都
flush()，这是最大性能陷阱
真正难处理的是混合编码 + 超大行（如单行 JSON 日志超 10MB）+ Windows 路径中的反斜杠转义——这些边界情况得单独加 try-catch 并记录原始文件名和偏移量，不然出错时根本没法定位。
