訪客帳號到底該怎麼設計？我有點後悔了 🤔

今天原本只是想「順手」把訪客帳號做起來，結果整個上午都被 AuthProvider 綁住。昨天還天真以為用 localStorage 放個暱稱就好，實作下去才知道麻煩在細節：訪客要不要能轉正式帳號、名稱怎麼同步、初始化狀態怎麼顯示，這些都不是一兩行就能搞定。

名稱同步最卡。一開始打算在 ProfilePage 處理，但切頁時會閃一下，整個很不專業。最後把邏輯拉回 AuthProvider，用 isInitialized 管初始化，至少不會再出現奇怪的名稱閃爍。只希望不要再冒出什麼邊界情況，真的拜託。

下午切到產品評論功能。訪客能不能留言這題，暫時定案：訪客不能直接留言，但會有「訪客資訊提示框」引導註冊，保留互動性，又不怕被 spam 灌爆。一起做了 @ 提及功能，本來 API 只存使用者名稱，後來想到改名就會爆，改成存使用者 ID，資料一致性才算穩。

晚上塞進去一直想做的膚質檢測。通知用了 react-hot-toast，本來擔心太花俏，實際效果比想像中舒服。整合時又踩了一個坑：導航列的連結，和個人資料頁的檢測卡片狀態要同步。本來以為很簡單，結果又在狀態管理上繞了一圈，最後決定用 context 讓狀態變化一致，總算過關。

每次遇到這種看不見的問題都會自問：「你真的需要這麼執著嗎？用戶會注意到嗎？」但心裡很清楚，這些細到看不見的 UX 累積起來，才會讓產品有差異。

收尾再整理問卷系統的 API 和資料庫模型。之前版本管理很亂，問題結構不一致，後端處理不同版本就得寫一堆 if。這次乾脆把版本檢查和新格式建立寫成自定義驗證器，要求問題結構一致。這種重構用戶根本不會注意，但未來維護應該會輕鬆一點，理論上啦。

回頭看，很多坑其實是自己一開始沒想清楚。特別是訪客帳號這件事，現在想想當初應該規劃得更仔細。不過創業跟開發就是這樣：邊走邊修，坑自己跳過一次才知道。今天跳過幾個，明天再繼續。