Bug 分析：異常對象復用導致堆棧信息錯位 —— 為什麼每次必須 new Exception？

異常對象在創建時會捕獲當前線程的方法調用堆棧快照。若嘗試復用同一異常實例（如定義為 static final 常量），拋出時將輸出創建時的堆棧，而非實際拋出位置，嚴重誤導問題定位。本文通過實例代碼深度剖析此陷阱，並給出正確實踐原則。

問題現場：靜態常量異常的「穿越」堆棧

public final class MyExceptionContext {
    // 類加載時一次性創建，堆棧定格在  階段
    public static final MyException x1 = new MyException("X1");
    public static final MyException x2 = new MyException("X2");
}

測試代碼在四個不同方法中拋出 x1、x2，但輸出的堆棧完全一致，均指向 MyExceptionContext.，且 x11 和 x21 明明拋的是同一異常，堆棧卻出現有無差異。

根因分析：堆棧快照在構造時刻凍結

• Throwable 構造函數 中調用 fillInStackTrace()，捕獲當前線程堆棧。
• static final 常量 在類初始化（）時創建，此時調用棧僅包含類加載路徑，與後續業務調用無關。
• 復用同一實例 意味著所有拋出點共享同一快照，完全喪失定位價值。

進階隱患：cause 鏈與可變狀態

異常常攜帶 cause（根因），若復用異常對象，cause 也會被固化，無法反映不同場景下的真實鏈路。且異常對象本身可變（如 setStackTrace），多線程復用更會引發競態條件。

正確姿勢：實時 new，捕獲真實現場

// ❌ 錯誤：靜態常量復用
throw MyExceptionContext.x1;

// ✅ 正確：現場實例化
throw new MyException("X1");

// ✅ 帶 cause 保留原始異常
throw new MyException("業務失敗", originalException);

最佳實踐清單

1. 永不將異常實例化為靜態常量，哪怕是無參構造。
2. 每次拋出必須 new Exception()，保證堆棧與業務上下文一致。
3. 異常鏈傳遞：構造時傳入 cause，保留完整因果鏈。
4. 自定義異常：提供多構造函數（message、cause、message+cause），便於豐富語義。
5. 單元測試驗證堆棧：斷言關鍵異常包含預期調用鏈關鍵類/方法。

核心口訣：異常即現場，現場不可復制，拋出必須重建。

理解此機制，能避免生產環境中「堆棧指向類加載器」的誤導性日誌，大幅縮短故障定位時間。