实现拼多多式分享返佣需用户生成带id的专属链接，服务端校验query.s和referrerinfo.extradata.s双来源，前端仅透传inviter_id并缓存，佣金由后端异步发放且二次校验。
要实现类似拼多多“分享赚红包”的交互流程，核心不是“把链接发出去”，而是让每个用户生成带自己 ID 的专属分享路径，并在被分享者完成关键动作（如注册、下单、支付）后，自动触发奖励结算。UniApp 本身不处理业务逻辑，但能可靠地传递和还原这些动态参数——前提是路径构造、页面接收、服务端校验三者严丝合缝。
onShareAppMessage 里必须动态拼接 shareUserId
静态 path 写死就等于放弃追踪能力。微信小程序要求 path 必须是已注册的页面路径，且不能含非法字符，但允许 query 参数。关键点在于：这个参数必须来自当前用户上下文，不能硬编码。
-
onShareAppMessage是个函数，不是对象，必须返回实时计算的结果；Vue3 的setup中需用ref或computed持有当前用户 ID，否则闭包会捕获旧值 - 路径中不要用
shareUserId=123这种裸露字段名，推荐缩写如s=123，既减少长度又规避部分风控规则 - 如果用户未登录，
shareUserId为空时，应 fallback 到一个默认页或提示“请先登录再分享”，而不是拼出s=这样的无效参数
pages.json 的 navigationStyle 不影响分享路径白名单
很多人误以为自定义导航栏会导致分享路径失效，其实微信校验的是 path 是否在 app.json 或 pages.json 的 pages 数组里注册过，跟 navigationStyle 完全无关。只要你的分享路径是 /pages/activity/redpacket，而该路径已在 pages.json 中声明，就不会报 “page not found” 错误。
- 真正容易被忽略的是：路径中不能出现
../、%、空格等非法字符，query 值必须encodeURIComponent编码（UniApp 的onLoad会自动解码，但你自己拼接时得编码） - 测试时别只看开发者工具，真机上微信对路径长度更敏感，建议总长度控制在 1024 字符以内
- 如果你用
uni.navigateTo跳转到分享页，也要确保目标页支持 query 接收，否则 onLoad 拿不到s
onLoad 里取不到 shareUserId？检查 options 和 referrerInfo
用户点击分享卡片进入页面时，onLoad(options) 的 options 对象里确实有 s，但仅限于从“分享卡片”直接打开。如果是从聊天窗口长按链接复制再粘贴打开，或者从朋友圈点击，options 为空——这时得靠 uni.getEnterOptionsSync() 拿 referrerInfo.extraData。
-
uni.getEnterOptionsSync()返回的对象里，referrerInfo只在从分享卡片进入时存在，且需要showShareMenu({ withShareTicket: true })才能拿到完整数据 - 服务端必须同时校验两种来源：
query.s和referrerInfo.extraData.s，缺一不可，否则裂变链路会断 - 前端拿到
s后，应立即存入uni.setStorageSync('inviter_id', s)，避免后续跳转丢失上下文
支付成功后怎么精准返佣？别在前端算金额
前端永远不该决定“该返多少”，只负责把 inviter_id 和订单号透传给后端。常见错误是：在 buyGoods 方法里直接调 sendCommission(123, 10)，这等于把佣金规则暴露在客户端，极易被篡改。
- 正确做法是支付成功后，调用你自己的下单接口（如
/api/order/submit），后端在创建订单时，从请求头或 session 中读取缓存的inviter_id，并关联到该订单 - 佣金发放必须由后端异步触发（比如监听支付回调事件），并做二次校验：是否新用户、是否首次下单、是否在有效期内、是否已发放过
- 前端只需显示“邀请人已获得红包”，具体金额和服务端返回为准，不要自己渲染数字
最易被忽略的点是：分享参数的生命周期管理。用户 A 分享了链接，用户 B 点开并注册，此时 B 的本地缓存里存了 A 的 ID；但如果 B 又点了别人 C 的链接，这个缓存不会自动覆盖或清空——必须设计明确的覆盖策略（比如每次进入带 s 的页面就重写，或加时间戳防重复）。否则会出现“张三分享的单子，最后算到了李四头上”。
