深鏈把應用路由暴露給瀏覽器、簡訊和其他應用。它可以直接打開訂單詳情，也可能帶來未知路徑、過期訂單 ID、重複導航，甚至把本應留在應用內的登入憑證放進 URL。
先解析，再導航
入口只接受已登記的 scheme 與 host，按允許清單匹配路徑，驗證參數長度和格式。外部 URL 不應直接轉成內部導航動作，更不能把 URL 中的 token 當作已登入證明。訂單 ID 只是定位信息；打開詳情仍需通過當前使用者會話向伺服器端鑒權。
收到 URL → 驗證來源格式與路徑 → 解析目標對象
→ 等待會話初始化 → 業務權限檢查 → 導航或錯誤頁
冷啟動和應用已在前景時都可能收到同一鏈接。路由層要能去重，並保證登入完成後只消費一次待打開目標。退出登入時清除待跳轉佇列，避免下一位使用者繼承上一個使用者的鏈接。
驗收要從外部應用發起
分別測試未登入、登入中、已登入和帳戶切換；再測試不存在的訂單、惡意編碼參數、同一鏈接連續點擊。只有在模擬器內部直接導航成功，不能證明真實深鏈配置與安全邊界正確。
一條邀請鏈接的可信邊界
用戶點擊 https://example.com/invite?code=... 後，系統可能把它交給應用，但“從系統回調進入”不等於鏈接可信。應用先解析固定域名與路徑，限制參數長度和編碼格式；再由服務端根據當前登錄身份校驗邀請是否存在、是否過期、是否允許該用戶接受。不要把 role=admin、價格或目標賬號等權限信息直接從 URL 變成業務狀態。未登錄時，只保存最小的待處理目標，登錄完成後重新向服務端查詢並確認權限。
對會產生副作用的鏈接，把“打開詳情”和“執行操作”分開。邀請頁可以展示服務端返回的組織名稱與權限說明，但接受邀請仍需用戶明確點擊；支付、轉賬、刪除等更不能在解析鏈接時自動執行。對外部回退網址採用固定 allowlist，不直接跳轉到任意 redirect 參數，否則鏈接會變成開放重定向入口。日誌中也不要寫完整令牌或邀請碼。
系統回調 → 規範化 URL → 域名/路徑/參數白名單 → 登錄狀態
→ 服務端查詢目標和授權 → 展示確認頁 → 用戶主動提交
驗證平台配置與異常輸入
iOS 的 Universal Links 需要域名關聯文件與應用 entitlement 匹配；Android App Links 需要可驗證的域名關聯。還要分別測試冷啓動、進程已運行、已登錄和未登錄，因為導航棧可能不同。輸入用例包括重復參數、過長編碼、大小寫變體、已撤銷邀請、跨賬號鏈接以及惡意外部跳轉。測試時確認無權限的目標既不顯示內容，也不產生服務器寫入。參考：Apple Associated Domains、Android App Links。