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 的时间也要纳入安排。停用服务不能作为回退目标，应准备已验证的网页或人工接续方式。完成后要交付网域与路由对照、测试结果、监察项目，以及谁负责日后更新。