Files.readAllBytes适合读取小文件（通常≤几MB），需根据JVM堆内存预判大小阈值，超限时应改用流式读取，并避免隐式内存放大；不适用于不可信大文件、部分读取或可扩展性要求高的场景。
Files.readAllBytes 适合读取小文件（通常建议 ≤几MB），它会一次性将整个文件加载进内存并返回 byte[]，用法简洁、代码清晰。关键在于“小”的界定和对内存影响的合理预判。
明确“小文件”的实际边界
所谓“小”，不是绝对值，而是相对于 JVM 可用堆内存而言：
- 默认情况下，单次读取超过 5–10 MB 的文件就可能引发明显 GC 压力，尤其在高并发或内存受限环境（如容器中 Xmx 设置偏小）
- 若应用堆内存为 512 MB，且需频繁读取多个文件，单个文件建议控制在 1–2 MB 以内更稳妥
- 可通过
Files.size(path)预检文件大小，超阈值时改用流式读取（如Files.newInputStream+ByteArrayOutputStream分块处理）
避免隐式内存放大
读取后若立即转成 String，需注意字符编码开销：
-
new String(bytes, StandardCharsets.UTF_8)会新建一个 char[]（UTF-8 下平均 1 byte → 2 chars），内存占用可能翻倍 - 如只需字符串内容且确定编码，可考虑
Files.readString(path, UTF_8)（Java 11+），内部做了优化，但本质仍是全量加载 - 若后续要解析 JSON/XML，直接用支持
byte[]输入的解析器（如 Jackson 的ObjectMapper.readValue(byte[], ...)），跳过 String 中间态
配合 try-with-resources 并非必须，但需注意异常语义
Files.readAllBytes 是原子操作，不涉及需显式关闭的资源，因此不用 try-with-resources。但它会抛出 IOException 和 OutOfMemoryError（当分配不到足够连续堆内存时）：
- 捕获
IOException处理文件不存在、权限不足等常规问题 - 对
OutOfMemoryError不建议 catch，而应通过预检大小 + 合理堆配置来规避 - 若读取的是临时/配置类小文件（如
application.conf），可加一层缓存（如ConcurrentHashMap存byte[]或解析后对象），避免重复读取
替代方案对比：什么情况下不该用它
以下情况应绕过 readAllBytes：
- 文件来自不可信来源（如用户上传），必须校验大小再读，否则易被恶意大文件触发 OOM
- 需部分读取（如只取前 1KB 做文件类型检测），用
Files.newInputStream+Channels.newChannel更轻量 - 文件逻辑上“小”但实际可能增长（如日志片段），应设计为流式接口，保持扩展性
