使用Web Share API时如何识别用户完成分享的目标应用

标准Web Share API场景下，完全无法在navigator.share()对应Promise的then回调中获取用户最终完成分享的目标应用信息。

• 按照当前正式发布的Web Share API标准，navigator.share()返回的Promise进入resolve状态时，仅代表用户走完了分享全流程、未主动中断操作，resolve的返回值固定为undefined，从规范设计上就没有预留携带目标应用信息的逻辑。
• 规范不开放这类数据的核心原因是隐私防护：如果Web页面可以无限制获取用户选中的分享应用，很容易被滥用用来收集用户的应用使用习惯、社交偏好，生成精准用户画像，这类敏感数据的外泄风险是规范制定方和浏览器厂商明确规避的。
• 即便是在catch异常回调中，能拿到的错误信息也仅为通用类型（比如用户主动取消、分享内容格式不被支持），同样不会附带触发错误的目标应用相关信息。

补充说明：早前Web Share API Level 2的草案中曾计划将分享目标应用信息纳入resolve返回值，但因隐私风险争议，该字段已被正式移出规范候选范围，没有落地的明确时间表。

很多开发者会尝试在then回调中读取返回值，实际能力边界和下面的代码逻辑完全一致：

if (navigator.share) {
  navigator.share({
    title: 'Hello world',
    text: 'This is a sample description',
    url: ''
  })
  .then((shareRes) => {
    // shareRes 固定为 undefined，不存在任何应用标识、应用名称类的字段
    console.log('分享流程完成', shareRes)
  })
  .catch((error) => {
    // 错误对象也仅包含通用错误码，无目标应用信息
    console.log('分享异常', error)
  })
}

额外提醒：目前公开的标准Web环境下，根本不存在可以让Web页面主动枚举本机全部可分享应用列表的公开API。如果你已经实现了枚举能力，大概率是基于自有WebView的桥接逻辑、或者定制浏览器的私有扩展API实现的，这类场景下的目标应用信息获取，完全依赖你自己的桥接代码能力，和标准Web Share API的能力无关。

• 自有WebView嵌入场景：完全绕开浏览器默认的navigator.share实现，自己在原生层封装分享面板逻辑，拿到用户选中的应用信息后，通过JS桥接口回传给Web层。
• 纯公开移动浏览器场景：没有合规的公开路径可以拿到目标应用信息，不要尝试通过篡改分享面板、监听系统行为的方式获取，既容易被浏览器安全机制拦截，也存在隐私合规风险。

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