YI

昨天猶豫了半天要不要接 Microsoft Clarity，今天早上看了幾段 session 錄影，心裡總算鬆一口氣——問題一目了然：搜尋輸入體驗太糟。輸入法組字的時機一錯，搜尋建議就瘋狂跳，整段流程像在考驗用戶耐心。 第一件事，我把搜尋輸入的 debounce 重寫：組字期間不觸發建議，等用戶完成再一次更新。順手加了清除按鈕，免得大家一直狂按退格。這些瑣碎的小事做完，我自己測起來順很多，心裡稍微安定。 真正麻煩的是 SEO。Next.js 升級到 App Router 之後，目錄結構整個換掉，原本的 Tailwind 設定和 SEO metadata 也得跟著改。我不愛花時間在看不見的細節，但 SEO 偏偏是曝光的基礎。於是我花了兩個小時，重整 Tailwind config，並把 metadataBase 交給 DefaultSEO

今天把幾件拖很久的事一次處理掉，專案也順了不少。 先把不用的 sitemap.ts 和相關邏輯清掉。本來以為是單純刪檔，結果測試掛了——有個測試竟然跟 sitemap 的生成耦在一起。把測試拆乾淨、舊案例順手整理後，CI 回到綠燈。像清掉房間的舊雜物，空出腦袋。 真正影響使用者的是條碼掃描。我當初只管「先跑起來」，沒考慮糊圖、掃不出或想手動輸入。後台回報顯示不少人卡在掃描直接棄坑。下午把掃描邏輯重構，加圖片上傳與手動輸入的備案，API 回應改成 ‎`{ barcodeExists: boolean, productId?: string }`，前端判斷更穩。猶豫了一下「會不會太複雜」，但看著用戶回饋，只能說：給選擇，才不會卡住。 順著把 FAQ 和 About Us 也更新。FAQ 去掉過度技術的描述，用白話把重點講清；About Us 調整產品展望，

軟刪除這件小事，背後的細節卻不小 原本只想補一個產品刪除 API。硬刪除直覺又乾脆，但總會有人手滑、客服就會來敲門。最後還是加了 deletedAt 欄位，用軟刪除留個回頭路。 一做下去才發現沒那麼單純：所有產品查詢都要顧到「未刪除」的狀態，沒有 WHERE deletedAt IS NULL 就會漏風。服務層邏輯跟 API 文件也都得跟著調，免得前端看到回傳數量不對又一臉問號。 刪除做完，回頭補分類查詢。前一晚還在想：「分類過濾真的有人用嗎？」如果首頁只放「最近分析的產品」，確實沒什麼意思。乾脆把首頁改成分類區塊，產品頁也補上分類過濾。React 端只是狀態篩選，沒太多問題；後端就麻煩了。 一開始用判斷 categoryId 的單層過濾，寫到一半才想到還有子分類。只好改成遞迴，把子分類的產品一併撈進來，測試也補齊，避免邊界情境漏掉。 今天接前端馬上踩坑：原本只有一層下拉，後端已經支援子分類，前端卻還是平面結構。

圖片輪播的坑，比我想的深得多。昨天把 .gitignore 的怪事整理完，今天回到產品開發，把待辦清單裡的圖片輪播放進度。原本估半小時的小元件，結果一做就發現邊界狀況一堆。 先是圖片 URL 的檢查，避免破圖。寫到載入狀態才真正頭痛——使用者網路慢，圖片還沒載好，輪播就先動，那體驗直接崩。我改成所有圖片載完再開始輪播，空檔用 placeholder 撐住。以為穩了，接著又遇到載入失敗要怎麼處理？最後還是每張都加 onError，統一顯示 fallback 圖。不浪漫，但必要。因為破圖看起來不只像 bug，更像品牌管理失敗。 前端收尾後回到 API。產品分類查詢本來是簡單的 CRUD，結果分頁＋子分類一上場，原本的產品資料模型就不夠用了，查詢邏輯整個打結。只好重構模型，補上子分類結構，連產品分析服務的主要功能也一起調整，讓「產品質地描述」的提取跟新架構對齊。這種調整就是牽一髮動全身，漏一角，