第十三天加了分類和截止日，但清單只能整份顯示。今天讓使用者可以依分類篩選，同時處理昨天發現的新增後排序位置不對。

今天做的事
後端的GET /api/todos改成可以接收?category=作業 這種參數，有帶才加上 WHERE 條件：

const { category } = req.query;
let sql = 'SELECT * FROM todos';
const params = [];

if (category) {
  sql += ' WHERE category = ?';
  params.push(category);
}
sql += ' ORDER BY due_date IS NULL, due_date ASC';

前端在新增區下方加了一個篩選下拉選單，切換時重新向後端要資料。新增待辦事項成功後，也不再自己把項目塞到畫面最後面，而是重新呼叫一次loadTodos()，順序就會是後端排好的。

觀察

• 網址問號後面那串?category=作業叫query string，後端用req.query讀取。前面學過的:id是放在路徑裡的參數，query string則適合放可有可無的條件，像篩選、搜尋、分頁
• SQLite排序時，沒有截止日（NULL）的資料預設會排在最前面，跟直覺相反。加上due_date IS NULL當第一個排序條件，沒日期的項目才會沉到最後
• 第六天寫的GET /api/todos/:id其實還在讀已經刪掉的todos陣列，只是前端都沒用到，所以一直沒被發現。今天順手改成查資料庫。這提醒我，把資料來源換掉的時候，要把所有用到它的地方都找一遍
• 昨天的排序問題，原因是新增後只在畫面最後面塞一筆，沒有重新排序。今天改成新增後重新載入，問題就解決了。代價是多打一次API，但換來畫面和資料庫的順序一致。

卡關
今天改完程式碼後，終端機完全沒有出現請求紀錄，執行node server.js還會印出伺服器啟動於...之後直接跳回提示字元，沒有任何錯誤訊息。我一度懷疑是自己把計時Middleware或app.listen改壞了，反覆檢查程式碼都沒找到問題。
後來推測是舊的伺服器還在背景執行，占住了port 3000，新啟動的那個其實沒有成功。更讓人困惑的是，Express 5 在啟動失敗時也會呼叫listen的callback，我的程式沒有檢查錯誤，所以照樣印出啟動成功。我把callback改成會檢查錯誤的版本，並用taskkill關掉舊的node程序。
這次的教訓是：看到啟動成功的訊息，不代表真的成功，程式要有處理錯誤的情況，才看得到真正的原因。

心得
今天的重點是畫面和資料要同步。篩選、排序、新增，三件事都靠同一個loadTodos()重新跟後端要資料，比自己在前端手動維護順序可靠很多。