今天原本打算輕鬆一點，先把產品頁面改成 client-side component，畢竟之前 SSR 時效能跟 UX 都有點卡卡的。

這一週的工作成果，老實說成果很不錯，但內心的感受卻是五味雜陳。這週把 Ingrelens 的 API 架構、環境變數管理、會員系統與帳號刪除功能都做了一次全面的整理與升級。從 HTTP 升級到 HTTPS、統一 API endpoint、Dockerfile 和環境變數自動化腳本的建立，一直到會員驗證流程與帳號刪除功能的完整重構，算是把過去半年累積的技術債務一次性還清了不少。 從技術面來看，這次的整理確實讓整個系統的可維護性和擴充性都有顯著提升。尤其是環境變數的自動化管理腳本，雖然一開始寫起來有點痛苦，但現在看來，這個腳本已經成為我部署流程的最佳幫手，未來再也不用擔心手動改錯環境變數而出錯了。再加上 API 統一管理，前端開發體驗也大幅改善，後端的穩定性和安全性也更高了。這些都是這週值得拍拍自己肩膀的地方。 但回頭看，我也發現自己過去幾個月累積了太多「看起來不急」的問題，才導致這週在整理的時候一次爆發，花了大量的時間與精力。像 API endpoint 不一致、URL 寫死在各個 component 裡、會員系統設計初期考慮不夠周全等等，這些技術債務累積下來的成本，

今天一整天幾乎都跟會員系統槓上了。說真的，當初設計 Ingrelens 時，沒想到會員功能會變得這麼複雜。從一開始只是想讓使用者簡單註冊登入，到現在竟然得處理會員資料更新、密碼修改，甚至還要支援 guest 帳號升級成正式會員，整個邏輯複雜度直線飆升。

有些東西放著不管就像是技術債務的定時炸彈，哪天一換環境就直接炸開來給你看。於是狠下心來，一口氣把 API URL 的處理邏輯全部抽取出來，改用環境變數統一管理，順便還給它做了個 trim 處理，避免環境變數前後多了空白符號導致的莫名其妙錯誤（我真的受夠這種鳥問題了 😑）。

昨天剛搞定 Dockerfile 跟環境變數，今天起床後第一件事就是想著：「Danny，你昨天寫的那個環境變數腳本真的沒問題嗎？」沒錯，果然一驗證就發現少考慮了一個場景：GitHub Token 的設定居然沒包含進去。

今天的第一個挑戰，其實昨晚睡前就開始煩惱了：「Danny，你 Dockerfile 裡的啟動命令是不是又亂寫了？」果然，一早檢查 deployment log 時發現，前端的 CORS 一直在鬼叫，後端 API 的 domain whitelist 根本沒吃進去。

昨天我才剛在成分搜尋上折騰完，覺得 BEAPI-26 的模糊匹配算是穩定了，今天本來想專心處理前端的錯誤處理，結果一開工就發現 API 整合出了大問題。 ingrelens-app 的 api-client 設定亂了套，開發環境的 URL 不一致，害我花了早上好幾小時在 debug，修到後面順便整個大重構XD 說到後端，ingrelens 專案的 BEAPI-27 需求延續了昨天的搜尋主題，並優化了產品列表的關鍵字搜尋功能，支持同時搜尋名稱和品牌。 情緒上來說，當我看到搜尋結果 finally 正常回應時，鬆了口氣，但也意識到這些優化得基於真實用戶反饋——不然再好的技術也只是自我陶醉。 除了這些我還在前端加了安全分析功能到 ProductDetailPage，如果沒有現有分析，就觸發 API 呼叫並重定向，引入 isRedirecting 狀態來管理 UI，避免跳轉時用戶看見空白畫面。 refactor 時，我把品牌過濾和麵包屑導航整合進 ProductsPage，用的 React Router，

昨天我才剛在品牌 API 上加了分頁和搜尋，覺得終於能鬆口氣轉移到前端的錯誤處理，結果今天一開工就深陷成分管理的沼澤。

這一週過得真是又累又充實，從週一的產品管理CRUD優化一路拼到週六的分析結果重構，我感覺自己像在打一場持久戰，邊修邊學，腦袋裡不斷盤旋著「這步棋到底對不對」的自我對話。

昨天我才剛處理完 ProductAttributes 的重構，原本以為今天能輕鬆接續前端的 error handling，結果一早我就被後端的品牌 API 問題給吸進去了。