java编译器在语法层面禁止catch(t e)，因为jvm异常分发依赖具体类名，而类型变量t无运行时类身份，无法生成合法catch表项，且jls明确要求catch参数必须是类类型而非类型变量。
Java 编译器在语法层面直接禁止 catch (T e) 这样的写法，根本原因在于：异常处理机制与泛型类型擦除存在底层语义冲突，编译器必须在语法解析阶段就切断这种非法表达，而非等到类型检查阶段才报错。
catch 块要求精确的、可静态识别的异常类类型
JVM 的异常分发机制依赖字节码中明确的 catch 指令目标——它匹配的是具体的类名（如 IOException）及其继承关系，不接受任何类型变量或泛型参数。而 T 是一个类型变量，它在源码中没有确定的运行时类身份，甚至可能尚未被绑定（比如出现在泛型方法或泛型类内部）。编译器无法为 catch (T e) 生成合法的字节码 catch 表项，因为该表项必须指向一个真实存在的类。
-
catch子句不是普通变量声明，而是控制流契约的一部分，其类型必须能参与异常检查（checked exception verification） - 编译器需验证
throws声明与catch类型是否兼容（例如能否捕获、是否是Throwable子类），而T的上界未知或不固定，无法完成该验证 - 即使
T被约束为extends Exception，擦除后T变成Exception或其上界，但catch (Exception e)和catch (T e)语义完全不同：前者明确捕获所有Exception实例；后者暗示“只捕获某种特定参数化的异常”，而这在运行时根本不存在
编译器不给擦除后“补救”机会
不同于泛型方法调用或集合操作，catch 语法在 Java 语言规范中被定义为只能接受类类型（ClassType）或类型参数为 Throwable 子类的限定类类型，而明确排除了类型变量（TypeVariable）。JSR-14 和 JLS 第14.20节规定：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
A catch clause declares a single parameter of type Throwable or a subclass thereof. The type must be a class type, not a type variable.
这意味着 T 在语法树构建阶段就被判定为非法，不会进入后续的类型擦除流程。编译器不会尝试“擦除 T 后再判断是否合理”，而是直接拒绝解析。
对比其他泛型场景，凸显 catch 的特殊性
-
List<t></t>允许存在，是因为它仅用于编译期类型检查 + 运行时安全转换，不改变字节码结构 -
throw new T()不合法，但错误发生在“实例化”环节（new要求具体类），而非语法定义层 -
catch (T e)错误更早：它违反了 Java 语法本身对catch参数类型的硬性限制，属于 syntactic prohibition，不是 semantic error
本质上，这不是编译器“保守”或“懒惰”，而是语言设计的必然选择——让异常处理保持确定性、可验证性与 JVM 兼容性，绝不把类型变量引入控制流契约。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
