一、基本型別初始化陷阱
成員變數（欄位）
- JVM 自動賦予預設值（
int→0、boolean→false、引用→null），不會編譯錯誤。
- 隱患：預設值常非業務預期（如年齡 0、狀態 false），導致邏輯錯誤。
- 最佳實務：宣告時顯式初始化
private int age = 18;，或在建構子設定。
區域變數
- 無預設值，編譯器強制要求初始化後才能使用，否則編譯失敗。
- 這比 C++ 僅警告更安全，避免「定時炸彈」進入生產環境。
- 習慣：宣告即初始化
int sum = 0;，即使稍後重新賦值。
二、方法回傳型別設計錯誤
- 無回傳值：必須宣告
void，而非省略。
- 型別相容性：回傳值可隱式向上轉型（
int → double），不可向下（double → int 編譯錯誤）。
- 呼叫端配合：接收變數型別須與回傳型別相容（
double d = obj.getPrice() 若回傳 int 合法；若回傳 double 接 int 則錯）。
- 文檔契約：團隊開發時，Javadoc 必須明確標註回傳型別與含義，避免整合錯誤。
三、參數列表個數與型別不匹配
- 一一對應：呼叫傳入參數須與簽名順序、個數、型別完全一致。
- 防禦性檢查：公開 API 應在方法開頭驗證參數合法性（
if (arg == null) throw new IllegalArgumentException(...)）。
- 型別轉換風險：強制轉型（
(int) doubleVal）可能截斷資料，需評估可接受誤差範圍。
- 前端攔截：UI 層用下拉選單、日期選擇器、必填驗證，盡早在使用者端攔截錯誤輸入，降低後端異常率。
總結檢查清單
- 所有欄位是否顯式初始化？
- 區域變數使用前是否已賦值？
- 方法回傳型別是否精確表達業務意圖？
- 公開方法是否有參數驗證與完整 Javadoc？
- 前端輸入控件是否限制了資料型別與必要性？
養成這些習慣，能消除 80% 以上的 Java 類設計低級錯誤，顯著提升代碼健壯度與團隊協作效率。
