直接用 window.share 失败是因为微信内置浏览器不支持原生 share api，必须通过微信 js-sdk 调用 wx.updateappmessagesharedata 等接口实现分享。
为什么直接用 window.share 会失败？
微信内置浏览器不支持原生 share API，所有“一键分享到朋友圈/好友”的逻辑必须走微信 JS-SDK。但很多人卡在第一步：调用 wx.config() 报错 config:invalid signature。这不是前端代码写错了，而是后端签名生成时 jsapi_ticket 缓存过期、nonceStr 重复、或当前 URL 没有提前在公众号后台「JS接口安全域名」中配置。
实操建议：
- 前端发起分享前，先向自己后端请求一个带签名的配置对象（含
appId、timestamp、nonceStr、signature），不要把签名逻辑放前端 - 后端生成签名时，必须用当前页面完整 URL（含 hash 前的部分，如
https://a.com/invite?uid=123），不能是带#/xxx的路由地址 - 测试时用微信「调试工具」打开页面，看
WXDebug控制台是否报invalid url domain—— 这说明域名没备案或没加进 JS 安全域名列表
邀请链接怎么带参数又不被微信砍掉？
微信会清洗 URL 中的 query 参数，尤其是 ?ref=abc 这类明显用于追踪的字段，容易被拦截或重定向。直接拼参不可靠，得靠微信的 updateAppMessageShareData 和 updateTimelineShareData 动态设置分享卡片的 link 字段。
实操建议：
- 用户进入页面时，用
location.search提取原始邀请码（如?inviter=U789），存在localStorage或内存变量里 - 在
wx.ready()后，调用wx.updateAppMessageShareData({ link: `https://a.com/invite?inviter=${inviter}` })，这样点击分享出去的链接才真正携带参数 - 避免在 URL 中使用下划线开头的参数（如
_t=123），微信某些版本会静默过滤 - 如果要用短链，确保短链服务支持透传参数（比如跳转时把
inviter写进 302 Location 头）
如何防止刷邀请、识别真实好友点击？
纯前端判断 from: 'timeline' 或 from: 'session' 不可靠，微信客户端可伪造 referer。真实防刷必须依赖后端结合 openid + 场景值（scene）+ 时间窗口。
实操建议：
- 生成邀请链接时，后端为每个用户生成唯一
scene值（如invite_123_1715678900），通过微信二维码接口createQRCode落地为带参数的临时二维码 - 被邀请人扫码进入时，微信会把
scene传给后端回调地址（https://a.com/callback?event=SCAN&scene=invite_123_1715678900），此时才能确认关系链成立 - 前端展示“你已被 XXX 邀请”时，不要只信 URL 参数，要等后端返回校验结果（比如调用
/api/check-invite?code=xxx接口）再渲染 - 同一个
scene只能绑定一次，且有效期建议设为 7 天，过期即失效
分享卡片标题和描述为什么总是不更新？
微信会缓存分享卡片元信息，哪怕你改了 updateTimelineShareData 的内容，旧设备可能仍显示上次的标题。这不是 bug，是微信客户端本地缓存策略。
实操建议：
- 每次调用
updateTimelineShareData时，在title或desc末尾加个轻量扰动，比如时间戳毫秒数的最后两位：title: `邀请好友得红包！${Date.now() % 100}` - 避免在页面加载完成前就调用分享接口；必须等
wx.ready()触发后再 set 数据 - 真机测试务必清空微信缓存（我遇到过 iOS 微信缓存卡片长达 24 小时，重启微信无效，只能删 App 重装）
裂变页面最麻烦的从来不是写 HTML，而是签名、场景值、缓存三者咬合的时机。漏掉任意一环，用户看到的都是“分享失败”或“无法识别邀请关系”。别迷信前端拦截，关键校验点全在后端回调和微信服务器的交互里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
