因为 SequenceInputStream 的构造器接收 Enumeration，若该 Enumeration 在首次遍历后已耗尽，则后续文件无法读取；需确保每次调用都提供未耗尽的新 Enumeration 实例。
用 SequenceInputStream 串联多个 FileInputStream 时，为什么只读到第一个文件？
因为 SequenceInputStream 的构造器接收的是一个 Enumeration extends InputStream>，不是直接传多个流对象；如果手动构建枚举时没正确包装或提前关闭了某个流，后续流根本不会被遍历到。
- 必须把每个
FileInputStream包装进Vector或其他支持elements()的集合，再调用elements()获取枚举 —— 直接传数组或列表会编译失败 - 所有输入流在构造
SequenceInputStream前不能关闭，否则构造时就抛IOException -
SequenceInputStream本身不自动关闭底层流，必须显式管理生命周期，否则文件句柄泄漏
Java 7+ 推荐用 Files.copy() + Stream 拼接，而不是手撸 SequenceInputStream
老方式写起来绕、容易漏关流、异常处理分散；新方式更直观，且能复用标准库的缓冲与异常传播逻辑。
- 对每个
Path调用Files.newInputStream()，放进Stream<inputstream></inputstream>，再用Stream.reduce()合并成单个InputStream - 但注意：
reduce的累加器函数里不能直接 newSequenceInputStream，因为需要动态构造枚举 —— 更稳妥是用InputStream数组 + 自定义合并逻辑（如循环 copy） - 最简实践：用
try-with-resources循环调用Files.copy(input, output, StandardCopyOption.APPEND)，省去流合并逻辑，也避免内存堆积
StandardCopyOption.APPEND 在 Windows 和 Linux 下行为一致吗？
一致，但仅限于 Files.copy() 写入普通文件时；它依赖底层 OS 的 open(O_APPEND) 行为，JVM 层已封装好兼容性。
- 第一次写入必须不用
APPEND（否则空文件追加会报No such file），后续才启用 - 如果目标文件不存在，带
APPEND会抛NoSuchFileException—— 必须先确保文件存在，或改用StandardOpenOption.CREATE, StandardOpenOption.WRITE, StandardOpenOption.APPEND组合 - 不要对同一个
OutputStream多次调用Files.copy(..., APPEND)：每次都会重新打开文件，性能差；应复用一个FileChannel或OutputStream
合并大文件时内存暴涨或卡死，是不是缓冲区没设好？
不是缓冲区大小的问题，而是默认 copy 使用 8KB 缓冲，对 GB 级文件仍够用；真正瓶颈常出在没禁用 FileChannel.transferTo() 的零拷贝优化 —— 它在某些 JVM + 文件系统组合下反而退化。
立即学习“Java免费学习笔记（深入）”；
- 显式指定缓冲大小没坏处：
Files.copy(in, out, StandardCopyOption.REPLACE_EXISTING)不暴露缓冲参数，所以得退回到InputStream/OutputStream手动 copy - 用
byte[] buf = new byte[64 * 1024]配合in.read(buf)+out.write(buf, 0, len)，比默认更可控 - 关键点：别在循环里反复 new
FileInputStream/FileOutputStream，尤其是输出流 —— 每次打开文件都触发系统调用，小文件多时延迟明显
实际写的时候，最容易被忽略的是输入流的关闭时机和 APPEND 模式对文件存在的强依赖 —— 这俩错一点，工具就静默失效或只写一半。
