OAuth 解除綁定的取捨：那些看起來很小、其實很難的決定

OAuth 解除綁定的取捨：那些看起來很小、其實很難的決定

早上打開昨天調完的 UI，間距問題總算舒服多了。從 Clarity session 看，滑動速度降了一些，心情小小被安慰。結果沒高興多久，Google OAuth 解除綁定流程又跳出來提醒我：直覺跟安全，要怎麼一起兼顧？

一開始以為不難：按個按鈕、呼叫 API、revoke token，收工。真的動手後才發現，OAuth 的麻煩全在細節。曾經寫了 revoke Google token 的邏輯，想說乾淨一點，避免用戶下次登入被多問授權。仔細想想其實沒必要 access token 本來就會過期，主動撤銷意義不大，還平白增加 API 呼叫與錯誤處理。最後我把這段整個拔掉，回到「只更新本地綁定狀態」的做法；流程更直覺，延遲也少了。

接著遇到更棘手的情境：用戶是用 Google 註冊的，解除綁定之後怎麼處理登入？系統裡根本沒有他的密碼，會不會變成幽靈帳號？我第一個反應是「那就登出所有裝置吧」。寫完又覺得太暴力：有些人只是要換綁定的 Google 帳號，被迫全部重登體驗很差。最後我在 UI 補了一道門檻——跳出對話框清楚告訴他「解除綁定後會登出所有裝置」，請他確認。雖然多了一步，但至少把預期講清楚，避免突然被踢出而困惑。

把 OAuth 的邏輯整理完，順勢把會員相關說明也更新，省得之後自己回頭看滿頭問號。EmailChangeForm 也做了控管：對 OAuth 用戶直接隱藏修改電子郵件，因為那是提供者控的欄位，讓用戶改只會製造更多混亂。

下午看 Clarity 跟 Google Analytics 的載入方式，想到 GDPR 的 Cookie Consent 一直沒好好收。之前是直接載入分析工具，根本不管同意狀態；長期下來有法規風險。於是把 CookieConsent 與 MicrosoftClarity 改成動態載入，GoogleAnalytics 則依 consent 決定是否放分析 Cookie。說不定很多人不在意，但這種小洞不補，最後要嘛變技術債，要嘛造成流失。

另外也把 Navbar 的效能債清了一輪。Clarity 看到點擊有卡頓，打開原始碼才發現先前 debug 留了一堆 console.log。清掉後順手用 useCallback 包事件處理，避免每次渲染都生新的函式。這種不起眼的小調整，移動端的反應其實差很多。

帳號刪除流程也被迫改設計。原本要輸入密碼確認，但 OAuth 用戶壓根沒有密碼。於是拿掉密碼確認，改成靜默拿一次 Google token 驗證身分，刪除流程更合理、也更直覺。

最後為了可存取性，把解除綁定按鈕從 onClick 改成原生 form submit，鍵盤操作與無障礙都更好一點。看起來只是微調，但產品成熟之後，這些細節反而會變得重要。

回頭看這兩天，很多 commit 都是在刪東西。奇怪的是，移除比新增更需要判斷與勇氣。做產品最難的，往往不是把功能做出來，而是決定哪些該做、哪些不做、哪些要「少做」尤其面對安全、體驗與維護成本的拉扯。沒有標準答案，只能持續觀察用戶，持續問自己：「這樣真的比較好嗎？」也許就在這些小小的取捨中，慢慢接近心裡那個理想的樣子。