throws仅用于编译期检查，声明受检异常以提醒调用方处理，jvm运行时忽略；不可替代throw或try-catch；多异常建议按具体到宽泛排序；接口实现可缩小但不能扩大throws范围；泛型和lambda中受限。
throws 声明只影响编译期检查，不改变运行时行为
Java 中 throws 出现在方法签名里，纯粹是给编译器看的——它告诉调用方：“这个方法可能抛出这些受检异常（checked exception），你得处理”。JVM 在运行时完全不关心 throws 列了什么，哪怕你写 throws IOException, SQLException，实际却抛出 NullPointerException，程序照样跑。
常见误解是以为 throws 会“触发”或“包装”异常，其实它只是契约声明。没声明却抛出受检异常（如 new FileInputStream("x.txt")），编译直接报错：Unhandled exception type FileNotFoundException；但抛运行时异常（RuntimeException 及其子类）永远不用声明。
声明多个异常时顺序无关，但建议按继承关系从具体到宽泛
一个方法可以 throws IOException, SQLException, IllegalArgumentException，编译器不校验顺序，也不要求它们有继承关系。但对人来说，把更具体的异常放前面更易读，比如：
void readConfig() throws ConfigFileNotFoundException, InvalidConfigException, IOException
而不是把 IOException 放最前——后者是父类，后面两个都继承自它，放前面反而掩盖了业务语义。
立即学习“Java免费学习笔记（深入）”；
-
throws Exception虽合法，但等于放弃异常意图表达，调用方只能统一catch (Exception e)，无法做差异化处理 - 如果方法内部
throw new SQLException()，但签名只写throws IOException，编译失败：子类异常不能“向上转型”进 throws 列表（除非用throws Exception） - 接口方法声明了
throws X，实现类可以缩小范围（比如不写throws或只抛更具体的子类），但不能扩大（比如加抛Y）
与 try-catch 和 throw 的协作关系容易混淆
throws 不是 throw 的替代品，也不是 try-catch 的简化写法。三者分工明确：
-
throw是主动抛出一个异常实例（如throw new IllegalArgumentException("id null")） -
try-catch是在当前方法内拦截并处理异常，处理完就“消化”掉了，调用方看不到 -
throws是把异常“甩给上层”，自己不处理，但必须让调用方知道风险
典型错误：在 catch 块里捕获后啥也不干，然后在方法签名加 throws ——这既没处理异常，又误导调用方以为“这里真会往外抛”。正确做法是：要么在 catch 里处理掉（如打日志、返回默认值），要么重新 throw 或 throw new XxxException(e) 并在签名中 throws 新异常。
泛型方法和 lambda 中 throws 的限制常被忽略
泛型方法无法在声明中直接约束类型参数抛什么异常。例如下面写法是非法的：
<T extends Throwable> void doWork() throws T // 编译错误：throws 后不能跟类型变量
lambda 表达式也受限：函数式接口的方法若声明了 throws，lambda 主体里抛出的异常必须是其子类型，且调用处仍需处理。例如：
Consumer<String> c = s -> { throw new IOException(); }; // 编译失败：Consumer.accept() 没声明 throws
此时必须换用自定义函数式接口，比如：
interface ThrowingConsumer<T> { void accept(T t) throws Exception; }
再用 ThrowingConsumer<string> c = s -> { throw new IOException(); };</string> 才合法——但调用 c.accept("x") 时，依然要包在 try-catch 里。
这些边界情况不常遇到，但一旦踩中，错误信息往往不指向 throws 本身，而是抱怨“unreported exception”，容易绕弯路。
