Files.newInputStream()仅打开流不加载内存，真正决定是否全量加载的是后续读取方式；应避免readAllBytes()等全读方法，改用8KB缓冲区循环read()流式处理。
Files.newInputStream() 本身不读取内容，它只返回一个 InputStream；真正决定是否“加载到内存”的是后续怎么用这个流——关键不在怎么打开，而在怎么读。
为什么不能直接“读取内容”又不加载内存？
所谓“读取内容”，如果指调用 Files.readAllBytes() 或 Files.readString() 这类工具方法，那必然全量加载。这些方法内部会申请与文件等大的字节数组，对大型二进制文件（比如 >100MB）极易触发 OutOfMemoryError。而 Files.newInputStream() 只是打开句柄、返回流对象，开销极小，但你必须自己控制读取节奏。
正确做法：用流式分块读取 + 显式缓冲区
用 Files.newInputStream() 配合手动 read() 调用，每次只处理固定大小的字节块。核心是避免一次性把整个文件拖进堆内存。
- 始终指定缓冲区大小，例如
byte[] buffer = new byte[8192]（8KB），不要用无参read() - 检查
read()返回值：它返回实际读到的字节数，可能小于缓冲区长度，也可能是 -1（EOF） - 不要用
readAllBytes()、readNBytes(int)（除非你明确知道 N 很小）或任何封装了“全读”的第三方工具类 - 如果目标是复制或转发，优先用
Files.copy(input, output)—— 它内部已做流式分块，且默认用 8KB 缓冲
示例片段：
try (InputStream is = Files.newInputStream(path)) {
byte[] buf = new byte[8192];
int n;
while ((n = is.read(buf)) != -1) {
// 处理 buf[0] 到 buf[n-1] 这 n 个字节
processChunk(buf, 0, n);
}
}
常见踩坑点：看似流式，实则偷偷全加载
以下操作会让 Files.newInputStream() 的努力白费：
- 传给
new DataInputStream(is)后立刻调用readFully(byte[])，且数组长度等于文件大小 - 包装成
BufferedInputStream但接着调用available()并据此分配超大数组（available()在文件流中常返回 0 或不准确） - 用
InputStream.transferTo(OutputStream)时，目标OutputStream是ByteArrayOutputStream—— 这会导致全部内容累积在内存 - 使用某些 JSON/Binary 解析库（如 Jackson 的
ObjectMapper.readValue(InputStream, ...)）解析大型二进制结构体时未配置流式模式，导致内部缓存全量数据
最易被忽略的是：你以为在“流式处理”，其实下游某个封装方法悄悄把流转成了字节数组。只要路径里出现任何 byte[] 接收全文件长度的地方，就得停下来查清楚它到底从哪来的。
