Intro Optional Param

Intro Optional Param

Intro Optional Param

Intro Optional Param

不建議用 Optional 作為方法參數，是因為 Java 官方設計理念和主流最佳實踐強調 Optional 主要用於「回傳值」型別，
作為方法參數會產生語意混淆、不易維護且降低 API 可用性。

主要原因
設計原則：Optional 原本就是表示「方法回傳時有或沒有值」、協助消除 null，並不是設計來當作參數型別。

API體驗降低：呼叫者必須手動包裝變數為 Optional，讓 API 使用變繁瑣，也常造成 Optional 或 null 混用的潛在問題。

多餘巢狀風險：很容易出現 Optional<Optional> 的巢狀結構，讓後續取值、流程管理更加複雜.

語意不明：參數本該只標註可否為 null，不需要求外部包裝成 Optional；萬一包錯、傳 null Optional，語意更混亂。

可讀性與維護性：程式碼閱讀、維護時會增加不必要的 Optional 裝/拆行為，且不符合 Optional 作為「回傳意義」的原設計.

正確用法建議
方法參數直接用標準型別（如 String），允許 null，進入方法後在需要用 Optional.ofNullable(x) 包裝即可。

參數若必須可選，標註 @Nullable 並於方法內統一處理，不需要求外部用 Optional 包裝。

總結：Optional 只適合作為回傳型別表達「有或無」，而不建議用於參數型別。參數用一般型別更直觀、精簡，程式碼也更易於維護和理解。
參數不建議用 Optional 的原因主要在於 Java 官方設計習慣與最佳實踐。Optional 的本意是用於「回傳型別」表示可能沒有值，並不是設計給方法參數用來表達是否有值。

方法接收參數時本來就支援 null 傳入，直接傳值並在內部包裝成 Optional 判斷就好，不需要呼叫方額外用 Optional.<…> 包裝。

如果用 Optional 作為參數，API 呼叫者必須自己封裝參數為 Optional，既繁瑣又容易產生 Optional<Optional> 的冗贅結構。

這使 API 不易使用、邏輯混亂且維護性降低（尤其日後 refactor 容易出錯），與 Optional 的「回傳可有可無」主設計原則違背。

最佳實踐是參數允許 null，於方法內包裝成 Optional 處理。Optional 用於回傳，參數只需清楚標註 null 能否接受與保護安全即可。