编译期类型检查是java编译器的硬性拦截机制，而非提醒或警告；它在泛型擦除前基于显式或推导类型执行静态验证，违规即报错中断编译，确保类型安全始于源头。
编译期类型检查不是“提醒”，而是硬性拦截
Java 编译器（javac）在解析源码时，会基于显式声明的类型（或 var 推导出的类型）执行静态验证。一旦发现违反类型契约的操作，直接报错、中断编译，不生成 class 文件。这不是警告，更不是可忽略的 lint 提示。
常见被拦住的场景包括：
-
String s = 123;—— 右侧是int字面量，左侧声明为String，编译器拒绝赋值 -
List<integer> list = new ArrayList<string>();</string></integer>—— 泛型参数不兼容，编译失败，而非运行时报ClassCastException -
list.add("hello");在List<integer></integer>上调用 —— 编译器查实该类无接受String的add方法重载，报Cannot resolve method 'add(java.lang.String)'
泛型擦除不等于“没检查”，检查发生在擦除前
很多人误以为“泛型运行时没了，所以编译期检查也不牢靠”。事实相反：类型擦除是编译后期动作，而类型检查是前期强制步骤。编译器先用完整泛型信息做全量校验，确认合法后才擦除并插入必要的 checkcast 指令。
例如这段代码：
List<string> names = new ArrayList(); names.add(42); // ❌ 编译报错 String first = names.get(0); // ✅ 无需 (String) 强转，且编译器已确保 get() 返回 String </string>
关键点：
-
names.add(42)在泛型检查阶段就被拒，根本不会走到擦除环节 -
names.get(0)的返回类型被推导为String，所以能直接赋值给String变量；擦除后字节码里其实有隐式checkcast，但那是兜底，不是主力防线 - 你不能靠反射绕过这个检查 ——
javac不提供任何“跳过类型验证”的开关或 flag
instanceof 和强制转换不是编译期检查的替代品
instanceof 是运行期判断，它解决的是“不确定来源的对象是否可信”这类动态场景，比如从 Object 集合取值、反序列化结果、HTTP 响应体解析等。但它本身不参与编译期类型约束。
典型误区：
- 写
if (obj instanceof String) { s = (String) obj; }是补救，不是设计 —— 如果本该用List<string></string>却用了List，就说明类型契约从源头就松动了 -
instanceof null返回false，不会 NPE，但这只是避免空指针，并不提升类型安全性 - 泛型擦除后，
List>或Object[]里的元素类型在运行期确实不可知，此时instanceof是必要手段，但它的存在恰恰反衬出编译期检查的边界：它只管你“怎么写”，不管别人“往里塞了什么”
接口与实现类返回值不匹配时，编译器照样拦截
当接口方法声明返回 IOrder，而实现类方法返回 Order（且 Order 实现了 IOrder），这是合法的协变返回 —— 编译通过。但如果实现类返回的是 Payment（未实现 IOrder），javac 会立刻报错：bad return type in method override。
真正容易漏掉的是这种情形：
- 接口定义
public IOrder getOrder(); - 实现类写成
public Order getOrder() { return new Order(); }—— 合法 - 但调用方写了
IOrder order = service.getOrder(); Order o = (Order) order;—— 看似顺理成章，却把风险推给了运行期 - 更安全的做法是让接口方法就返回具体类型
Order，或在服务层用泛型封装，避免裸 cast
编译期检查的威力，取决于你把类型契约设在哪一层：越靠近数据源头（如集合、接口、方法签名），它拦得越早、越准；越往后拖（比如到展示层再强转），就越依赖运行期防御，也越容易出问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
