Firebase Dynamic Links 停用後：舊連結、App 邀請與電郵登入怎樣修復？

先把問題分成四段

抽取一條真正仍在使用的連結，由「收到」一路跟到「完成」。例如會員邀請：電郵內的 URL 能否打開？已安裝 App 時會否到指定邀請？未安裝時能否在安裝後繼續？最後接受邀請的是否正確帳戶？四個答案分別涉及網址、路由、安裝接續及身份／業務規則，不能只用「App 開到了」作結論。

• 列出入口：電郵範本、SMS、WhatsApp、網站、推送、印刷 QR 及 App 內分享。
• 每條連結記錄網域、用途、目的畫面、建立來源、是否要登入，以及能否重新發出。
• 抽查舊版及新版 App；開發版正常，不代表商店正式版也正常。

舊 page.link 不能靠你的伺服器補救

先看網域由誰控制。Google 的 page.link 網域不能保留或轉移；在自己的網站加 redirect，也接收不到指向舊 page.link 的請求。這類連結需要換網址：修改可編輯的入口，重新發出邀請，並為已寄出的訊息或印刷品提供清楚的補救途徑。

若舊連結使用你持有的自訂網域，可評估重新接管該網域的 HTTPS 服務，保留已知路徑。不過保留網域不代表找得回每個短網址的目的地。要先找當時的匯出檔、資料庫、發信紀錄或活動清單；只有短碼、沒有對照資料時，不能承諾還原。官方說明舊連結 metadata 會在停用後刪除，現在不應把重新匯出當作可靠的救援方案。

Firebase — Dynamic Links deprecation FAQ

選擇替代方案前，先決定要保留甚麼

只需要讓已安裝 App 打開指定內容，可先評估 Android App Links 與 Apple Universal Links，再為沒有 App 的訪客提供有用的網頁。若需求是「按邀請、去商店、安裝、首次開啟後仍回到同一邀請」，則還要處理 deferred deep linking。單純導向商店，並沒有完成這項需求。

可比較 Branch、AppsFlyer 等服務，也可選擇明確的手動接續，例如安裝後再開原電郵、輸入短期邀請碼，或登入後顯示待處理邀請。後者可能已足夠支援一個小型會員流程，但要讓用戶知道下一步。比較時要求供應商示範你的實際裝置及渠道，並查清費用、資料收集、網域擁有權、匯出及退出安排；不要把「支援 deep link」當成所有功能都相同。

Firebase — Migrate to App Links and Universal Links · Branch — Firebase Dynamic Links migration

電郵登入要另外驗收

Firebase Authentication 有以 Firebase Hosting 取代舊 Dynamic Links 的手機電郵連結方案。要核對的不止 SDK：也包括產生連結的設定、手機接收新網域的設定，以及 App 收到 URL 後是否完成相應的登入操作。Android 與 iOS 各有官方遷移步驟；Flutter、React Native 或低代碼工具亦要核對其實際使用的原生 SDK 和 build 設定。

不要為了修好登入，把有效期限、一次性使用或帳戶核對刪掉。邀請和登入也應分開：拿到邀請 URL 不代表有權加入客戶公司；真正接受時，伺服器仍需檢查帳戶、邀請狀態與權限。分析紀錄只保留流程結果及錯誤類別，避免收集完整登入 URL、驗證碼或 token。

若原本流程會在另一部裝置開啟電郵，亦要測試：Firebase 電郵連結登入需要核對收件地址。不要把 email 放進 URL 再直接信任它。密碼重設與電郵驗證應各自測試；Dynamic Links 停用並不代表所有 Firebase 網頁電郵操作也停用。

Firebase — Android email-link migration · Firebase — iOS email-link migration · Firebase — Email-link authentication and security

在客戶真正收到的訊息上測試

從瀏覽器直接貼上 URL 成功，只能證明其中一個入口。電郵發送工具可能把網址包成追蹤連結；WhatsApp 或其他 App 可能用內置瀏覽器；同一條網址在不同入口的行為未必一致。請保留一份實際收到的測試電郵，查看第一個點擊的 hostname，以及每一步轉向，而非只測最後的目的地。

Android 要核對 App Links 驗證狀態與正式簽署憑證；iOS 要核對 Associated Domains 及 apple-app-site-association。不要用加長等待時間來掩蓋網域設定錯誤。先確認平台有否把網址交給 App，再查 App 是否把收到的路徑帶到正確畫面。

尤其在 iOS，直接在瀏覽器網址列輸入 URL，不會因此開啟 App；同一網站內的導覽亦可能留在瀏覽器。請按下測試訊息內的連結來驗收，不要把這些預期的瀏覽器行為誤判為修復失敗。

Android Developers — Verify App Links · Apple Developer — Debugging universal links

把「完成」寫成可以逐項重做的測試

第一輪可只修復一種高優先用途，例如現有會員的電郵登入。以下清單是起點，應按你的流程補上實際預期結果。每項保存 App 版本、OS、入口渠道、是否已登入及最後結果，交付時附上失敗情況與支援安排。

• App 已安裝：冷啟動及已開啟時，都到指定內容；需要登入時，登入後仍保留目的地。
• App 未安裝：清楚顯示下一步；只有承諾了安裝後自動接續，才把該功能列為必須通過。
• 過期、已用及被撤回邀請：顯示明確結果，可安全地要求重新發出；重按不會建立第二筆會員或訂單。
• 不同帳戶及不同裝置：不能誤認身份或越權；敏感內容不會出現在公開預覽頁。
• 正式發信與分享渠道、最新商店版及仍受支援的舊版均有測試；失敗可以追查，但紀錄沒有登入秘密。

委託修復時，先交出流程及失敗樣本

準備可重現的測試連結、App 商店網址與版本、網域清單、發信來源、用途優先次序，以及舊網址對照資料。測試帳戶與已遮蓋敏感資料的畫面通常比一句「Firebase 壞了」更有用。不要透過普通電郵傳送管理員密碼或 service account key；需要存取時，再安排適當的授權。

報價範圍宜分清調查、網址處理、App 更新、發信修改及驗收；商店審批與客戶更新 App 的時間也要納入安排。停用服務不能作為回退目標，應準備已驗證的網頁或人工接續方式。完成後要交付網域與路由對照、測試結果、監察項目，以及誰負責日後更新。