今天加上截止日期欄位，讓待辦事項能依時間排序，越緊急的排越前面。

今天做的事
在 todos 資料表新增 due_date 欄位，並把 GET /api/todos 改成：

db.all('SELECT * FROM todos ORDER BY due_date ASC', (err, rows) => {
  ...
});

前端新增一個 讓使用者選擇截止日，renderTodo 也跟著顯示截止日期文字。測試後確認清單確實依日期由近到遠排列。

卡關一：新增後排序位置不對
新增一筆截止日是2026-10-07的待辦事項後，發現它沒有出現在該在的位置（跟另一筆同樣10-07的項目相鄰），反而被加到整個清單最後面。一開始以為是排序邏輯寫錯，檢查後端的SQL語法確認沒問題，重新整理頁面後，這筆資料確實移動到正確的位置了。
後來理解到：後端的排序只有在「重新呼叫一次 GET」的時候才會生效。新增成功後，前端呼叫的renderTodo(newTodo)只是單純把新項目塞進畫面最後面，並沒有重新排序整個清單。這提醒我前端畫面的顯示順序，跟後端資料庫查詢出來的順序，其實是兩件分開的事，不會自動同步——除非重新整理頁面、重新跟後端要一次排序好的資料。

卡關二：分類預設值沒有生效
另外發現一個現象：新增待辦事項如果沒有特別去點分類選單，每次送出的分類都自動變成「作業」，而不是資料庫設定的預設值「未分類」。
原本以為資料庫的category TEXT DEFAULT'未分類' 會自動套用，後來才發現這跟資料庫完全無關，是標籤本身的特性：瀏覽器沒有特別指定selected屬性時，永遠會自動選中清單中第一個，剛好我寫的第一個選項就是作業。所以前端每次送出的category值本來就都是作業，資料庫的DEFAULT根本沒有機會派上用場——它只有在完全不傳category欄位的情況下才會生效（例如直接用 Thunder Client 測試時）。
這讓我理解到：資料庫的 DEFAULT 是最後一道防線，不能拿來取代前端介面本身該有的預設狀態設計，兩者要分開處理，各自負責各自的層面。

心得
今天雖然功能本身（加欄位、排序）寫起來不難，但兩個卡關都指向同一個主題：前端畫面的狀態，跟後端資料的狀態，是兩條平行線，不會互相自動同步。排序要同步，得重新打一次API；預設值要同步，得前端自己去設定。這種畫面看到的跟資料庫存的之間的落差，應該會是接下來持續會遇到的課題。