核心是通过方法重载与流包装实现输入源归一化：File、Path、InputStream、byte[]、String等均映射为InputStream，由统一doParse(InputStream)处理，兼顾兼容性、安全性和易用性。
用流包装配合方法重载，核心是让工具类对不同来源的输入（如 file、path、inputstream、byte[]、甚至 string）提供统一方法名，靠参数类型自动分发到最合适的处理逻辑，不破坏旧代码，也不强制用户做类型转换。
流包装是桥梁，不是终点
工具类本身不直接操作原始文件系统或网络流，而是把各种输入“归一化”为 InputStream 或 ReadableByteChannel。例如：
-
File→ 调用file.toPath().getInputStream() -
Path→ 直接调用Files.newInputStream(path) -
byte[]→ 包装成new ByteArrayInputStream(data) -
String（含编码）→ 先转bytes再包装
这些转换逻辑不暴露给调用方，全由重载方法内部完成。
重载设计要覆盖常见输入形态
一个健壮的文件处理工具类通常提供以下静态重载方法（同名、同功能、不同入参）：
-
parse(File file)—— 兼容老项目中大量使用的java.io.File -
parse(Path path)—— 支持 NIO.2，更安全、可扩展 -
parse(InputStream in)—— 最底层抽象，适合框架集成或内存流场景 -
parse(byte[] data)—— 避免临时文件，适合微服务间二进制传输 -
parse(String content, Charset charset)—— 面向文本内容，省去编码转换步骤
所有方法最终都委托给同一个核心处理逻辑（比如 doParse(InputStream)），确保行为一致。
注意歧义与优先级陷阱
重载不是堆砌，必须规避编译器无法抉择的情况：
- 避免同时定义
parse(InputStream)和parse(ReadableByteChannel)：两者在传Channels.newChannel(in)时可能产生歧义 - 不要让
parse(String)和parse(File)共存且未加约束：传"config.json"会被当作内容还是路径？应改用parseAsString(String)或明确命名 -
byte[]和ByteBuffer可共存，但需注意：传ByteBuffer.wrap(bytes)会优先进入ByteBuffer版本，而非byte[]版本
向后兼容的关键细节
一旦发布，已有重载方法不能删、不能改签名（哪怕标记了 @Deprecated）：
- 旧版本 JAR 被新项目依赖时，若移除
parse(File)，会导致NoSuchMethodError - 新增重载应尽量复用已有逻辑，例如
parse(Path p)内部调用Files.readAllBytes(p)后再走parse(byte[])，而不是另起一套解析流程 - 若需扩展（如加超时、加校验），用额外参数重载（如
parse(File, boolean validate)），而非修改原方法
