MyBatis-Plus (MP) 提供的 Wrapper (如 QueryWrapper, LambdaQueryWrapper, UpdateWrapper, LambdaUpdateWrapper) 是其核心特性之一，它允許我們在開發時以面向對象的方式構建 SQL 的 WHERE 條件、ORDER BY、SELECT 字段列表等部分。與傳統的 MyBatis 在 XML 文件中編寫動態 SQL 相比，使用 Wrapper 優劣勢如下：

使用 Wrapper 構建動態 SQL 查詢的優勢 (Advantages):

1. 代碼即查詢，更 Java 化 (Code is Query, More Java-Centric):

   • 查詢邏輯完全在 Java 代碼中完成，無需在 Java 和 XML 文件之間頻繁切換上下文。
   • 對于 Java 開發者來說，使用熟悉的鏈式調用 (fluent API) 構建查詢條件通常更直觀、更符合面向對象的思維。
   • 易于利用 Java 的編程能力動態構建查詢條件，例如根據復雜的業務邏輯 if/else 來添加不同的查詢條件。

2. 類型安全 (Type Safety - 特別是 LambdaWrapper):

   • 使用 LambdaQueryWrapper 或 LambdaUpdateWrapper 時，可以通過方法引用 (如 User::getName) 來指定數據庫字段，而不是硬編碼字符串 (“name”)。
   • 這帶來了編譯期檢查的好處：如果實體類的字段名發生重名（rename），編譯器會報錯，強制你修改查詢代碼，極大的減少了因字段名拼寫錯誤或重構遺漏導致的運行時錯誤。原生 XML 中的字符串則無法在編譯期檢查。

   // Type-safe using LambdaWrapper
   LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
   wrapper.eq(User::getName, "John Doe").ge(User::getAge, 30);// Less safe using QueryWrapper with hardcoded strings
   QueryWrapper<User> wrapperStr = new QueryWrapper<>();
   wrapperStr.eq("name", "John Doe").ge("age", 30); // Typos in "name" or "age" only found at runtime
   

3. 友好的 IDE 支持 (Better IDE Support):

   • 在 IDE 中我們可以使用自動補全、語法高亮、重構等。
   • 編寫 Wrapper 時，可以方便的查看方法、參數提示。

4. 代碼簡潔性 (Conciseness for Common Cases):

   • 對于許多常見的、不太復雜的動態條件組合，使用 Wrapper 的鏈式調用通常比編寫 XML 中的 <if>, <where>, <foreach> 等標簽更簡潔。

5. 易于組合和復用 (Easier Composition & Reuse):

   • 可以將構建 Wrapper 的部分邏輯封裝成獨立的方法或工具類，在不同的查詢場景中復用，提高了代碼的模塊化程度。

使用 Wrapper 構建動態 SQL 查詢的劣勢 (Disadvantages):

1. 復雜 SQL 的受限 (Limited Expressiveness for Complex SQL):

   • 對于非常復雜的 SQL 查詢，特別是涉及多表連接 (JOIN)、子查詢、聯合查詢 (UNION)、復雜的聚合函數 時，使用 Wrapper 可能會變得非常困難。
   • 強行用 Wrapper 實現復雜 SQL 可能會導致代碼可讀性急劇下降，不如直接在 XML 中編寫原生 SQL 清晰。

2. SQL 不直觀，可讀性下降 (SQL Obscurity & Reduced Readability for Complex Cases):

   • 排查sql語句比較費勁，SQL 語句需要依賴日志輸出或調試才能看到。

3. 對 MP API 的學習成本 (Learning Curve for MP API):

   • 開發者需要學習 Wrapper 提供的各種方法 (eq, ne, like, gt, lt, in, between, isNull, orderBy, groupBy, select, apply 等) 的用法和含義。

4. 靈活性限制 (Flexibility Limitations):

   • 雖然 Wrapper 提供了 apply() 方法來拼接原生 SQL 片段，但這在一定程度上破壞了 Wrapper 的類型安全和面向對象的優點。如果大量使用 apply()，可能還不如直接寫 XML。
   • 對于某些數據庫特有的高級特性或優化提示 (Hints)，Wrapper 可能目前沒有更好的支持。

總結與建議:

• 適用場景: Wrapper 非常適合處理單表或簡單關聯（可以通過 MP 的 Join 插件或少量自定義 SQL 補充）的動態條件查詢，尤其是在需要類型安全和代碼簡潔性的場景下。對于大部分日常的 CRUD 和條件過濾、排序等操作，Wrapper 是極其高效的選擇。
• 局限場景: 對于涉及復雜的多表連接、子查詢、聚合、特定數據庫函數等高級 SQL 操作，或者需要進行性能優化的場景，直接在 XML 中編寫原生 SQL 通常是更佳、更靈活。
• 最佳實踐: 混合使用 MyBatis-Plus 允許我們無縫的混合使用 BaseMapper 的通用方法、基于 Wrapper 的查詢以及在 XML 中定義的自定義 SQL。
  • 對于簡單的、通用的、需要動態條件的查詢，優先使用 LambdaWrapper 以獲得類型安全和簡潔性。
  • 對于復雜的、性能敏感的、Wrapper 難以表達或表達不清的查詢，毫不猶豫的在 XML 文件中編寫。

選擇使用 Wrapper 還是 XML dynamic SQL，關鍵在于根據查詢的復雜度、對類型安全的要求、團隊的熟悉度以及對SQL 可控性與可讀性的需求來權衡。