成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應
這兩天主要在處理兩件事：把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理，全都被牽出來重整了一遍。
先說成分搜尋。之前後端只有陽春 CRUD，前端要找成分時不是一次吐一大坨資料，就是用 JavaScript 自己過濾，效率慘不忍睹。這次把品牌 API 重寫後，順手把成分關鍵字搜尋補齊，採用 PostgreSQL 的 ILIKE + %keyword% 做模糊查詢。pg_trgm 有想過，但成分名稱不如品牌那麼複雜，現在用 ILIKE 就夠。測 API 時踩到 Windows 的 multiprocessing 老問題：spawn 啟動方式和 Linux 的 fork 不同，程式會卡在奇怪的地方。最後用 if name == “main” 包一層並 set_start_method(‘spawn’)，並發效能就回來了。
資料庫也順手整理。補上品牌表與產品表的外鍵，清掉沒有品牌的孤兒產品，寫 migration 把關聯性拉齊。原本品牌詳情用 SQLAlchemy 的 text 查詢，回頭看太繞，改用 ORM 工具方法直接處理，刪掉一堆冗餘碼，心情好不少。API 路由的前綴重複定義問題也一併處理，做了一個路由診斷 CLI，隨時檢視註冊的路由，並寫了一份路由設計最佳實踐文檔，避免之後再踩同樣的坑。
接著是整合上的大條。ingrelens-app 的 api-client 在開發環境 URL 不一致，早上整個在 debug 和重構。後端 BEAPI-27 延續昨天的搜尋主題，把產品列表關鍵字搜尋擴展到同時匹配名稱與品牌。前端 ProductDetailPage 加了安全分析的觸發機制：如果沒有現有分析，就呼叫 API 並重定向，加入 isRedirecting 狀態避免跳轉空白。ProductsPage 也把品牌過濾和麵包屑整合在一起，用 React Router 調整流程；為了避免 prop drilling，狀態改由 Context API 管理，雖然代碼多了些，但邏輯清楚。
整體看起來，這是一次從「看不下去的低效率」出發的全線修補。搜尋更乾淨、資料更有關聯、路由更一致、前端跳轉更穩。等到搜尋結果正常回來的那一刻，確實鬆了口氣。不過這些優化還是要回到真實用戶的反饋，否則只是自己覺得漂亮。至少目前的坑都補上了，下一步該讓使用場景來驗證這些改動值不值。
