Dev

軟刪除這件小事，背後的細節卻不小

原本只想補一個產品刪除 API。硬刪除直覺又乾脆，但總會有人手滑、客服就會來敲門。最後還是加了 deletedAt 欄位，用軟刪除留個回頭路。

一做下去才發現沒那麼單純：所有產品查詢都要顧到「未刪除」的狀態，沒有 WHERE deletedAt IS NULL 就會漏風。服務層邏輯跟 API 文件也都得跟著調，免得前端看到回傳數量不對又一臉問號。

刪除做完，回頭補分類查詢。前一晚還在想：「分類過濾真的有人用嗎？」如果首頁只放「最近分析的產品」，確實沒什麼意思。乾脆把首頁改成分類區塊，產品頁也補上分類過濾。React 端只是狀態篩選，沒太多問題；後端就麻煩了。

一開始用判斷 categoryId 的單層過濾，寫到一半才想到還有子分類。只好改成遞迴，把子分類的產品一併撈進來，測試也補齊，避免邊界情境漏掉。

今天接前端馬上踩坑：原本只有一層下拉，後端已經支援子分類，前端卻還是平面結構。補了第二層選擇器後，順手把多個 useState 重構成單一物件狀態，乾淨一點、後續擴充也容易。

API 參數也微調。一開始只有 categoryId，預設會把該分類與所有子分類通通回傳。想了想，有些情境只想看單一分類，不需要子分類。於是加了 includeSubcategories 參數，讓前端能明確指定是否包含子分類。API 稍微複雜一點，但彈性與清晰度更好。

另外，分類頁的圖片原先走動態 API。其實變動不大，每次打一次請求意義不大。改用靜態圖片，減少呼叫、載入也快一些。

看似只是兩個 API 的調整，做下去才知道細節很多。尤其軟刪除，看起來簡單，一動手就牽一髮動全身。以後遇到 CRUD 類功能，先多想十分鐘再寫，少挖坑、少補坑。

原來分類的坑比想像中還要深

昨天還在想軟刪除，今天就被分類功能教訓。後端加了子分類遞迴，前端如果只有一層選擇器，整個就卡住。重構狀態、補第二層選擇器後，流程順了不少。

API 規格也更貼使用者直覺：categoryId 決定分類，includeSubcategories 決定是否向下展開。該簡單的地方簡單，需要彈性的地方提供選項。

效能面也別忘了。分類頁圖片改成靜態，少一次請求就少一次等待，體感就差那一點點。

整體回頭看：需求不複雜，但要顧的面向很多。資料狀態（軟刪除）、層級結構（子分類）、前後端規格對齊、測試邊界、效能取捨。都不難，但就是要一開始就想清楚，少走回頭路。