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

尤其是訪客名稱同步這件事，原本想簡單在 ProfilePage 裡處理掉，但後來發現這樣名稱會在切換頁面時閃爍一下，整個看起來超不專業。最後還是把同步邏輯提升到 AuthProvider，用 isInitialized 狀態來管理初始化過程，這樣用戶至少不會看到奇怪的名稱閃現了吧？（拜託不要再有 edge case 拜託拜託 🙏）

下午切回產品評論功能，昨天猶豫的訪客評論問題，今天算是有了初步的解法。我決定訪客雖然還是不能直接留言，但可以透過「訪客資訊提示框」引導他們註冊正式帳號，這樣既保留了互動性，又不會被 spam 灌爆。

順便還做了一個 @ 提及功能，這個功能看起來很直覺，但後端處理起來其實蠻 tricky 的。一開始 API 只存了提及用戶的名稱，後來想想這樣萬一用戶改名不就完蛋了？只好再改一次 API，把提及用戶的 ID 存下來，這樣至少資料一致性比較有保障。

晚上終於抽時間把之前一直想做的膚質檢測功能給加上去了。這次特別用了 react-hot-toast 做通知，原本還擔心這個套件會不會太花俏，但實際用起來效果意外蠻舒服的（至少我自己看了很開心啦 🤭）。

不過整合的時候又碰到一個小坑：導航欄連結跟個人資料頁面的檢測卡片狀態同步問題。原本以為很簡單，結果又花了一個多小時在狀態管理上反覆調整，最後才決定直接用 context 處理，這樣狀態變化至少比較一致了。

這種問題每次都讓我懷疑人生：「Danny，你真的有必要這麼執著嗎？用戶真的會注意到這種細節嗎？」但我心裡還是很清楚，這種看不見的 UX 細節，累積起來才會讓產品真正有差異。

最後今天還花了點時間整理了問卷系統的 API 跟資料庫模型，之前的問卷版本管理實在有點亂，尤其問題結構一致性這個點一直沒處理好，導致後端每次要處理不同版本的問卷都要額外寫一堆 if 判斷。

這次索性把問卷版本檢查跟建立新格式的邏輯自定義驗證器來確保問題結構一致。雖然這種後端重構用戶根本不會注意到，但至少未來維護起來應該會輕鬆一點吧？（理論上啦，我也不敢保證 😅）

今天回頭看，很多問題其實都是自己之前沒想清楚造成的，尤其訪客帳號這個功能，現在想想真的有點後悔當初沒規劃得更仔細一點。不過創業跟開發就是這樣吧，邊走邊修正，總是會有些坑要自己跳過才知道。至少今天跳過了幾個坑，明天再繼續吧。