深链把应用路由暴露给浏览器、短信和其他应用。它可以直接打开订单详情，也可能带来未知路径、过期订单 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。