怎么利用 Files.readAllBytes() 一次性读取小文件的所有内容到内存字节数组
Files.readAllBytes() 适合读取多大的文件
一句话概括：它只适合处理那些真正意义上的“小文件”。通常建议文件大小控制在1 MB以内，原因很简单——这个方法会把整个文件内容一股脑儿地塞进堆内存。一旦文件体积超标，尤其是在JVM堆内存配置不大或者并发调用频繁的场景下，OutOfMemoryError 几乎就是板上钉钉的事。这个方法本身可不会帮你做任何大小校验或分块处理，你传给它一个500 MB的日志文件，它照样会尝试全部加载，结果可想而知。
- 安全阈值怎么定？ 这取决于你应用的堆内存配置，但保守一点总没错：生产环境里，超过100 KB的文件最好就别用它了。
- 哪些场景适用？ 临时文件、小型配置文件片段、图标、JWT密钥文件这类“小个头”才是它的用武之地。
- 不确定文件大小怎么办？ 先用
Files.size(path)检查一下，如果超限，果断换成Files.newInputStream()进行流式处理。
基本用法和必须捕获的异常
Files.readAllBytes() 在方法声明上只抛出一个 IOException，但在实际运行中，你更可能遇到的是它的子类，比如 NoSuchFileException（文件路径不存在）或者 SecurityException（没有读取权限）。记住，它不会静默失败，也不会返回 null——一旦出问题，直接就是异常伺候。
- 异常捕获有讲究： 别图省事只 catch 一个宽泛的
Exception。优先捕获IOException及其子类，这样能更清晰地分辨到底是路径问题还是磁盘I/O故障。 - 参数类型要留意： 路径参数必须是
Path类型，不能直接传String。记得用Paths.get(“config.bin”)进行转换。 - 标准用法示例：
try { byte[] data = Files.readAllBytes(Paths.get(“token.key”)); } catch (IOException e) { // 在这里处理文件不可读、不存在等情况 }
和 Files.readString()、DataInputStream 的关键区别
这个方法的功能非常纯粹：按字节原样复制，不做任何额外的“翻译”工作。它不会帮你解析文本编码，也不会进行结构化读取。如果你需要字符串，得自己手动用 new String(data, StandardCharsets.UTF_8) 转换；如果文件是JSON或Protocol Buffer格式，它也不会帮你反序列化。
- 与
Files.readString()的关系： 后者是JDK 11引入的，其内部实现其实也调用了readAllBytes()，然后再做一次UTF-8解码。所以，如果你最终目标就是字节数组，就别绕这个弯子了。 - 与
DataInputStream的对比： 如果你需要用DataInputStream来读取int、long这类特定类型，说明你的文件有固定的二进制格式。这时，readAllBytes()只是第一步，拿到字节数组后，你通常还得配合ByteBuffer.wrap(data)进行手动解析。 - 功能限制： 它不支持指定缓冲区大小，也不支持跳过BOM（字节顺序标记）。需要这些高级功能？那就得手动打开流来处理了。
Windows 上的路径与符号链接陷阱
在Windows环境下使用这个方法，有个细节特别容易踩坑：符号链接。如果路径指向的是一个符号链接（比如用 mklink 命令创建的），Files.readAllBytes() 默认会跟随链接（follow links），读取的是目标文件的内容。但问题在于，如果目标文件因为权限不足或跨卷等原因无法访问，它抛出的异常信息可能非常具有误导性——通常是一个笼统的 IOException，错误信息可能只写着“系统找不到指定的路径”，让你误以为是链接本身不存在。
- 提前检查链接： 可以使用
Files.exists(path, LinkOption.NOFOLLOW_LINKS)来确认符号链接本身是否存在。 - 控制链接跟随行为： 如果想明确控制是否跟随链接，就不能用
readAllBytes()了，得改用Files.newInputStream(path, LinkOption.NOFOLLOW_LINKS)配合手动读取。 - 路径书写规范： 使用绝对路径时，推荐写成
Paths.get(“C:\\data\\flag.bin”)这样的形式，避免单个反斜杠被误解析为转义字符。
话说回来，在实际应用中，最容易被忽略的两个风险点就是文件大小的前置判断和符号链接的隐式跟随行为。这两点平时可能相安无事，但一旦出问题，往往就是线上难以复现的偶发故障，排查起来相当头疼。务必多加小心。
