一、核心問題：從SQL重復執行到日志失效

1. 首要現象：XML重復查詢失效
在排查服務性能時發現：

<!-- MyBatis XML片段 -->
<select id="List" resultMap="Map">    
SELECT * FROM user WHERE name = #{name}     
<!-- 參數name為null時重復執行相同全表查詢 -->
</select>

癥狀：

• 相同SQL反復執行?

2. 調試暴露第二問題：日志輸出異常
為定位參數問題，在Controller添加日志：

log.info("請求參數: {}", userListDto); // 打印輸入參數

卻得到：

請求參數: com.domain.dto.user.UserListDto@599f4346  // 對象內存地址

后果：

• 無法識別空參數來源：日志無法展示實際傳入的name值

---

二、根因剖析：DTO斷裂引發的級聯故障

關鍵斷層點分析：

1. DTO層面：

   • 致命缺陷：缺少@Data導致：
     • toString()未生成 →?日志無法格式化輸出
     • getter未生成 →?Service層獲取name時隱含空指針風險
   • 文檔缺失：字段無注釋導致維護成本增加

     // UserListDto.java（問題版本）
     public class UserListDto {    
     private String name;   // 無業務注釋    
     private Integer pageNum;  // 未標識必填
     }

2. Controller層面（核心責任方）：

   • 未校驗入參：直接傳遞DTO到Service
   • 未處理日志：放任對象原始輸出

3. Service/DAO層面：

   • 參數未過濾：XML直接使用#{name}未判空 →?重復觸發全表掃描
   • 無緩存機制：相同查詢反復訪問數據庫

---

三、解決方案：修復數據鏈路

1. DTO層修正（止血點）

@Data // 核心修復！
生成toString/getter/setter
public class StickerListDto {    
// 增加必要注釋    private String name;       
// 貼紙名稱（可空）    private Integer pageNum;   
// 頁碼（必填）}

2. Controller層加固（責任方修復）

<JAVA>

/*** 獲取列表信息** @param dto 請求參數封裝對象* @return 貼紙列表信息*/
public TableDataInfo<UserListVo> getUserList(UserListtDto dto) {// 關鍵日志完善 → 打印完整且精準的參數信息log.info("請求獲取貼紙列表，參數為：Name = {}, PageNum = {}", dto.getName(), dto.getPageNum() == null ? "null" : dto.getPageNum());// 參數校驗增強 → 細化校驗邏輯，全面檢查參數合法性if (dto == null) {throw new IllegalArgumentException("請求參數整體為空，無法進行查詢");}if (dto.getPageNum() == null || dto.getPageNum() < 1) {throw new IllegalArgumentException("頁碼參數異常，必須為大于等于1的正整數");}// 補充對其他關鍵參數的校驗示例（按實際需求調整）if (dto.getName() != null && dto.getName().length() > 50) {throw new IllegalArgumentException("名稱參數過長，長度不得超過50字符");}// 正常業務邏輯調用 → 參數已校驗，可安全傳遞給服務層處理return productStickerService.getStickerList(dto);
}

---

四、核心經驗：Controller層的數據責任

1. DTO是Controller的盔甲：

   • 缺失@Data?≈ 解除防御 → 導致日志失效+參數穿透
   • 無字段注釋 ≈ 丟失地圖 →?增加協作成本

2. 日志是指紋采集器：

   • 打印對象地址 → 相當于案發現場無痕跡 →?完全喪失調試能力
   • 定制化日志格式（如name={}）→ 直接鎖定問題參數

3. 空參數是系統毒藥：

   • 未在Controller攔截 →?毒藥流入Service層
   • DAO層無防御 →?數據庫成為最終受害者

教訓總結：
UserListDto缺失@Data導致：

• 調試黑洞：日志輸出無意義地址符
• 安全缺口：空值穿透至DAO層
• 性能災難：XML重復全表查詢
  修復本質：在Controller層建立數據安檢站（DTO規范+參數校驗）