Java 靜態類型檢查機制圖解：編譯期 vs 運行期的類型安全邊界

核心概念

• 靜態類型檢查：基於源碼在編譯期驗證類型安全，阻擋類型錯誤進入運行期。
• 動態類型檢查：在運行期驗證類型安全（如強制轉型 (C) obj）。

Java 採用靜態類型檢查為主、動態檢查為輔的混合策略，核心目標：**「不要讓類型錯誤在運行期發生」**。

經典案例演示

場景：繼承鏈 A ← B ← C

class A { A me() { return this; } void doA() { println("Do A"); } }
class B extends A { void doB() { println("Do B"); } }
class C extends A { void doC() { println("Do C"); } }

1. 編譯期類型 vs 運行期類型

A a = new B().me();  // 編譯期類型：A  |  運行期類型：B
a.doA();             // ✅ 編譯通過，運行正常
a.doB();             // ❌ 編譯報錯：A 類型沒有 doB() 方法
((B) a).doB();       // ✅ 編譯通過（強制轉型），運行正常
((C) a).doC();       // ✅ 編譯通過（編譯器只看聲明類型 A 可轉 C），運行拋 ClassCastException

2. 為什麼編譯器允許 (C) a？

編譯器只知道變量 a 的**聲明類型是 A**，而 A 是 C 的父類，**理論上 A 的子類實例可能是 C**，所以編譯器樂觀通過。具體是否真的是 C，留待運行期檢查。

3. 靜態檢查的「保守性」

• 編譯器拒絕：new B().me().doB() —— 聲明類型 A 無 doB。
• 編譯器允許：((C) new B().me()).doC() —— 聲明類型 A 可轉 C，但運行期炸。

深度原理：類型系統與子類型多態

• 聲明類型：變量定義時的類型（靜態綁定，編譯期可知）。
• 實際類型：new 出來的對象類型（動態綁定，運行期可知）。
• 里氏替換原則 (LSP)：子類型必須能替換父類型。編譯器允許父類引用指向子類對象，但只能調用父類型定義的方法。
• 向下轉型風險：(Child) parentRef 需開發者自行保證運行期真實類型匹配，否則 ClassCastException。

最佳實踐：如何利用靜態檢查減少 Bug

1. 面向接口編程：變量聲明用接口/抽象類，縮小編譯期類型範圍，強迫依賴抽象而非實現。
2. 避免不必要的向下轉型：用多態、訪問者模式、instanceof 模式匹配（JDK 16+ if (obj instanceof String s)）替代強轉。
3. 泛型擦除陷阱：List 運行期變 List，編譯器插入隱式轉型，堆污染導致遠處拋異常 —— 用 @SuppressWarnings("unchecked") 謹慎標註。
4. 利用編譯器插件：Error Prone、NullAway、Checker Framework 在編譯期發現空指鈈、並發、單位等深層問題。

總結

Java 靜態類型檢查是**「編譯期基於聲明類型的保守近似」**。它保證：如果編譯通過，運行期不會出現「方法不存在」「字段不存在」等結構性錯誤；但無法保證強制轉型、反射、泛型擦除等動態行為的類型安全，這部分風險轉移給開發者通過測試、代碼規範、動態檢查來承擔。