接口中声明 throws ioexception 合法但不推荐，因其违背面向接口编程原则、增加调用方负担、阻碍实现替换；应优先使用 uncheckedioexception 或语义化运行时异常。
接口方法里写 throws IOException 合法但几乎没用
Java 接口中声明 throws IOException 语法上完全合法，编译能过，但实际开发中极少这么做——因为调用方无法绕过该检查，而绝大多数现代 IO 操作（比如基于 NIO.2 的 Files、Path）本身已改用运行时异常或返回值封装错误，强制声明反而破坏抽象。
更关键的是：接口定义应聚焦「做什么」，而非「怎么失败」。IO 异常是实现细节，暴露给接口会让所有实现类被绑定到具体 IO 方式（比如必须用 FileInputStream），违背面向接口编程原则。
真正需要声明 throws 的场景只有两种
一种是明确要求调用方处理的受检异常（Exception 子类且非 RuntimeException），比如自定义的业务异常；另一种是历史包袱严重的旧接口（如 java.io.Closeable.close() 声明了 throws IOException），此时子类/实现类必须遵守。
- 如果你在设计新接口，不要为
IOException声明throws，改用Optional<string></string>、Result<t exception></t>（如 Vavr）、或直接抛UncheckedIOException - 如果必须兼容老代码（例如实现
java.nio.channels.ReadableByteChannel），则按接口契约补上throws IOException，但注意：实现类里仍可抛UncheckedIOException（它是RuntimeException子类，不违反契约） - Spring 或其他框架的回调接口（如
ResourceLoader.getResource()）通常也不声明 IO 异常，而是统一转为IOException的子类（如FileNotFoundException）并包装成运行时异常抛出
throws IOException 在接口中会导致的典型问题
最常踩的坑是：写了之后发现所有实现类都得加 try-catch 或继续向上抛，结果业务逻辑被大量异常模板代码淹没，测试也难写——比如一个读配置的接口，本该关注「配置是否存在」「格式是否正确」，却被迫处理「磁盘满」「权限不足」等底层细节。
- 单元测试时，Mockito 无法 mock 带
throws的接口方法（除非用doThrow()显式指定，但破坏测试简洁性） - Lombok 的
@SneakyThrows不能用于接口方法（只对实现类方法有效） - 函数式接口（如
Supplier<string></string>）无法直接适配声明了throws IOException的方法，必须额外包装 - 如果接口被多个模块引用，某天你把 IO 换成内存缓存实现，就不得不改接口签名，引发连锁编译失败
替代方案：用 UncheckedIOException 更干净
这是 JDK 7 引入的运行时异常，专为包装 IOException 设计。它让你保留原始异常栈信息，又不用在方法签名里暴露受检异常。
public String readConfig() {
try {
return Files.readString(Paths.get("config.txt"));
} catch (IOException e) {
throw new UncheckedIOException(e); // 不用声明 throws
}
}
调用方看到的是运行时异常，可选择捕获或忽略；测试时也无需模拟异常路径——除非你真要验证异常处理逻辑。
真正难的不是语法怎么写，而是判断哪些错误该让调用方感知（比如「配置文件不存在」是业务关键态），哪些该吞掉或转义（比如「临时目录不可写」只是降级策略触发条件）。这层语义区分，比 throws 多写几个字重要得多。
