Dev

今天幾乎都在跟會員系統纏鬥。Ingrelens 一開始只是做「註冊、登入」這種基本功能，結果一路長出資料更新、密碼修改、guest 升級成正式會員……每加一個需求，整體邏輯就再複雜一點。 先處理 email 驗證。以前的流程只是寄信、點連結，直到要支援 guest 升級與 email 更改，原本設計就撐不住，尤其 verification metadata 完全不夠用。我改成以一個簡單的 JSON 欄位記錄驗證類型與必要資訊，流程比較有彈性。 接著踩到 profile_data 的坑：它不是每次都能穩定解析成字典，偶爾還會冒出 500。原因是某些地方沒做好 JSON parse 的錯誤處理。最後我強制所有 profile_data 至少回到 dict 型態；parse 失敗就回空字典，

游標分頁、環境變數與 API 統一大作戰：把炸彈拆完，才有力氣往前走 有些技術債務不會自己消失，換個環境就原形畢露。這兩天我乾脆把 API URL 的處理邏輯整個抽出來，用環境變數統一管理，再加上 trim，免得前後多了空白符號害人抓狂。順手把散落各處的 console.log 清一輪，才發現 ingredient 的 fetching 端點之前居然不一致，害某些成分 ID 會查不到。笑不太出來，只能重構，把 URL 結構對齊、確認每個 ID 都能讀到資料，附帶補上 error handling。下一次出問題至少能快速定位，而不是盯著螢幕問號連發。 API URL 收拾好後，回頭看最近做的游標分頁，總覺得哪裡卡卡。先前只有單向 next，自己測一測發現使用者一點「上一頁」

這兩天主要在補技術債、梳理架構，過程當然少不了自我懷疑，但也總算把幾個老問題收斂了。 先是 Dockerfile。昨晚就覺得哪裡怪，早上看 deployment log 才確認——前端 CORS 一直叫，後端 API 的 domain whitelist 根本沒吃到。追了半天發現是啟動命令寫法有問題，環境變數沒進去，CORS 就默默回到 localhost。這種低級錯誤不是第一次發生，每次都要再問自己一次：「你到底什麼時候才會記住？」好，這次除了修指令，乾脆把環境變數管理自動化，一個 bash script 負責切換 beta、dev、prod，順手把環境特定的 .env 加進 .gitignore，避免哪一天不小心把敏感資訊推上去。這種看起來小事，但出包就會後悔到爆。 API 這邊也趁機整理。把 api-client 的

成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應 這兩天主要在處理兩件事：把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理，全都被牽出來重整了一遍。 先說成分搜尋。之前後端只有陽春 CRUD，前端要找成分時不是一次吐一大坨資料，就是用 JavaScript 自己過濾，效率慘不忍睹。這次把品牌 API 重寫後，順手把成分關鍵字搜尋補齊，採用 PostgreSQL 的 ILIKE + %keyword% 做模糊查詢。pg_trgm 有想過，但成分名稱不如品牌那麼複雜，現在用 ILIKE 就夠。測 API 時踩到 Windows 的 multiprocessing 老問題：spawn 啟動方式和 Linux 的

延續昨天的 AI 整合反思，我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節，整個渲染邏輯就像多米諾骨牌一樣一路倒下：從前端元件、狀態流到資料處理方式，都被迫重新梳理。雖然頭疼，但結果讓我滿意。 先從「觀察互動」著手。我加了一個專門顯示成分的區塊，原本擔心資訊太細，使用者不一定在意，但測試下來，這一層補充反而讓分析更完整、點擊更少。順勢把整頁重構一輪，告別以前那種直接堆原始 JSON 的做法，資料管線變得順暢許多。commit 的時候我自嘲：「Danny，你以為加個屬性顯示就好？結果還是得把渲染邏輯全部理一遍，免得狀態打結。」好在錯誤率降了 25%，至少沒有再重演昨天的 CORS 驚魂。 後端我延續安全檢查的思路，改了 API 和資料庫的幾個環節。新增了不帶參數的產品建立與清單路由，讓系統自動處理預設值，不必每次請求都塞一堆冗餘資料。這個改動讓錯誤請求少了約三成，也減輕前端在弱網環境下的負擔。同時加上重複產品檢查與原始 SN 的取得邏輯，解掉之前條碼重複的麻煩。過程中我也踩到坑：

昨天把產品管理的 CRUD 骨架穩住後，今天直接把精力放在條碼掃描的擴展。理由很簡單：如果輸入數據不可靠，後面的分析再巧都只是表面工夫。 先整理了幾個後端細節，把多餘的 SQL 彈性收斂，移除那些看似靈活、實則增加風險的參數，順手解了一些依賴問題。結論很直白：簡化後更安全，查詢也不再繞路。 真正的麻煩在測試。新增了無效檔案類型、空檔案、損壞圖片、過大檔案等案例，還做了並發掃描的壓力測試。因為 CRUD 調整後，條碼必須唯一，不然產品建立會互撞。我把條碼欄位拉到 50 個字元以支援更多格式，結果第一輪就被並發情境打臉：同時掃描時資料庫鎖衝突，只好重做索引與鎖機制，半天就這樣沒了。 不過調整之後，建立流程穩定許多。我也把分析摘要的 API 從圖片上傳改成用產品流水號生成，少了上傳複雜度，JSON 結構更一致，回傳格式就不再時好時壞。文檔同步更新，錯誤碼與備援機制一並寫清楚。 情緒上還是會懷疑「這樣折騰值不值？」但這些看似瑣碎的調整，確實讓系統更結實。