如何识别跳转链接来源 据此加载Flutter Web应用对应内容

你可以按优先级选以下几种成熟方案，组合使用稳定性最高：

• 专属带参链接（主方案）：给每家合作餐厅分配全局唯一的身份标识，比如自定义短slug、数字ID，要求餐厅官网放置的跳转链接统一拼接该参数，例如披萨店的跳转链接为https://你的点餐应用域名?rid=pizza_001，快餐店的链接为https://你的点餐应用域名?rid=burger_002。Flutter Web端应用初始化时，直接通过Uri.base解析当前访问地址的query参数，拿到rid值后先请求后端校验标识合法性，校验通过就拉取对应餐厅的菜单数据即可。拿到合法rid后记得把值存在web端的本地存储（比如sessionStorage或者shared_preferences）里，避免用户在应用内跳转子路由、刷新页面时丢失来源标识。
• 专属路径/子域名方案：如果觉得带query参数的链接不够美观，可以给每家餐厅分配独立的访问路径，比如https://你的点餐应用域名/shop/pizza_001，或者分配独立二级域名https://pizza001.你的点餐应用域名，Flutter Web配置路由拦截规则，解析路径段或者域名拿到餐厅标识即可，逻辑和带参链接一致，用户感知更好。
• Referer兜底校验：浏览器发起跨站跳转时默认会携带Referer请求头，值为跳转前的页面地址。你可以提前把所有合作餐厅的官网域名存入白名单，当URL里没有携带餐厅标识时，后端可以解析请求头里的Referer值，匹配对应域名映射的餐厅。注意这个方案只能做兜底：部分用户的浏览器会开启隐私模式禁用Referer传递，部分餐厅官网也可能配置no-referrer策略导致Referer丢失，不能作为主识别逻辑。

落地注意：所有前端拿到的餐厅标识都必须传给后端做合法性校验，不要直接信任前端传值，避免用户恶意篡改参数访问非授权餐厅的内容；如果标识校验失败、所有识别逻辑都没拿到有效餐厅ID，直接跳转到公共的餐厅选择页即可，不要出现白屏、报错。

完全不适用这个场景。
Webhook的核心逻辑是「第三方服务端在特定事件触发时，主动向你的服务端推送事件数据」，但用户点击餐厅官网的链接跳转到你的应用这个动作，是用户端浏览器直接发起的页面跳转，整个流程里餐厅的服务端不需要、也不会在用户点击链接时主动给你的服务端发送任何回调请求，你根本无法通过Webhook接收到对应用户的跳转事件，自然也无法关联到具体的跳转来源。

内容的提问来源于stack exchange，提问作者ihatecoding