昨天把CRUD全部接上資料庫後，順手測試才發現一個漏洞：新增時什麼都不輸入，或者只打空白鍵，照樣能新增成功，清單上會出現一行看起來空空的項目。今天補上前後端兩層驗證，堵住這個破綻。

今天做的事
後端這邊，把原本簡單的if(!title)判斷加強：

const title = (req.body.title || '').trim();

if (!title) {
  return res.status(400).json({ message: '待辦事項內容不能是空白' });
}

用Thunder Client測試，刻意送出空字串、純空白、甚至完全不帶title欄位這三種情況，確認都會收到400而不是伺服器出錯或靜靜地新增一筆爛資料。
前端也加上同樣邏輯，輸入框空白時按新增會跳出提醒，並且不會真的發出請求，減少無意義的網路流量。

觀察

• (req.body.title || '').trim()這個寫法解決了一個潛在的當機風險：如果今天完全沒帶title欄位req.body.title會是undefined，直接呼叫undefined.trim()會讓伺服器丟出例外、整個請求當掉。先用|| ''給一個保底的空字串，就能安全地往下執行。
• 前端跟後端的驗證邏輯幾乎一模一樣（都是trim()之後檢查是不是空字串），一開始覺得好像在寫重複的程式碼，後來理解到：前端的驗證可以被繞過（直接用Thunder Client打API就跳過了前端），所以後端的驗證才是真正守住資料正確性的最後一道關卡，前端只是為了讓一般使用者操作體驗更好、少打一次不必要的請求。
• 錯誤處理那段if (!res.ok) { return res.json().then(err => { throw new Error(err.message) }) }，一開始沒抓到res.ok這個狀態，直接把失敗的回應當成功處理，導致新增失敗時畫面卻顯示新增成功的提示。後來才知道fetch預設不會把400、500這種狀態碼當成錯誤丟出來，要自己判斷res.ok。

心得
這次踩的坑讓我理解到一個很基本但容易忽略的觀念：前端看起來正常，不代表背後資料是乾淨的。如果只靠前端擋，繞過前端（例如直接呼叫 API）就能塞入任何奇怪的資料，資料庫裡遲早會累積一堆垃圾資料。信任使用者輸入是後端開發裡最危險的假設之一，這次算是提早體會到這一課。