昨天花了一整天整理 FindSkin™ 的命名和流程之後，今天我決定再多花點時間把首頁跟膚質檢測問卷的介紹區塊做得更清楚一點。畢竟昨天睡前我還一直在想：

今天整天都在執著於膚質分析這個功能的命名跟使用體驗，全部統一改成了「FindSkin」。

原本以為新增訪客帳號功能只是「順手」的事，結果今天花了整個上午在 AuthProvider 的邏輯裡來回糾結。昨天還很天真地覺得只要用 localStorage 存個訪客暱稱就好，但一實作才發現，光是處理「訪客帳號是否轉正式帳號」、「訪客暱稱的同步」跟「初始化狀態的顯示」就快把我逼瘋了。

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

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

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

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

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

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

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