Web Share API 的 navigator.share() 总是 resolve 且无结果反馈：其 Promise 在分享界面关闭后立即以 undefined 值 resolve，不区分成功或取消，仅同步错误会抛出异常；隐私设计决定网页无法获知实际分享行为。
Web Share API 不支持获取分享结果数据
Web Share API 的 navigator.share() 方法是单向的：调用后只能等待用户操作完成（分享成功或取消），但无法得知具体发生了什么。浏览器明确不返回任何“成功/失败”标识，也不提供回调、Promise resolve/reject 值来反映分享结果。
为什么 navigator.share() 的 Promise 总是 resolve
该 API 的设计原则是“隐私优先”——分享目标（如微信、邮件客户端、短信 App）运行在系统层面，网页无权知晓用户是否真的发送了内容、发给了谁、甚至是否点了“取消”。因此：
-
navigator.share()返回的 Promise 在用户关闭分享界面后**立即 resolve**，无论操作是分享、取消还是中途崩溃 - Promise 的
resolve值始终为undefined，没有任何有效字段 - 不会触发
reject，哪怕设备不支持、参数非法（此时会直接抛出同步错误）
try {
await navigator.share({ title: '标题', text: '正文' });
// 这里总会执行，不代表分享成功
console.log('分享界面已关闭'); // ✅ 总是打印
} catch (err) {
// 仅当 share() 调用失败时进入（如未在安全上下文、参数缺失）
console.error('无法打开分享界面:', err);
}
能做的有限检测：仅判断“是否进入分享流程”
虽然拿不到结果，但可通过副作用间接推测用户是否触发了分享动作（仍非 100% 可靠）：
- 监听
pagehide或visibilitychange：多数系统分享界面会切出当前页面，导致页面失焦或隐藏 - 检查
document.hidden状态变化：分享弹窗展开瞬间常触发visibilitychange - 注意：这些信号也可能是用户切到其他 Tab、锁屏、或被电话中断，不能等同于“已分享”
document.addEventListener('visibilitychange', () => {
if (document.hidden) {
console.log('页面不可见 —— 可能进入了系统分享界面');
}
});
替代方案：服务端埋点 + 客户端标记
若业务强依赖“分享完成”事件（如发放奖励），必须放弃纯前端判断，改用组合策略：
立即学习“前端免费学习笔记（深入）”；
- 分享前生成唯一
shareId，存入localStorage并附在分享链接中（如https://example.com?ref=abc123） - 用户点击该链接进入落地页时，服务端记录
ref=abc123并清除本地标记 - 客户端可设置短时定时器（如 3s），若期间
localStorage中的shareId未被清除，则认为“大概率未完成分享”
这个方案绕开了 Web Share API 的限制，但依赖用户最终点击链接——如果用户复制文字后手动发送，就无法追踪。
Web Share API 的核心约束就是“不可知”，所有试图从navigator.share() 拿到结果的尝试都会落空。真正需要闭环反馈的场景，必须把判断逻辑下沉到服务端，并接受一定比例的漏判。 
