用户A分享商品，用户B打开页面并下单，系统怎样把订单正确归因给A？很多方案把答案简化为“拿到OpenID”，但OpenID只能回答当前用户在特定应用范围内是谁，不能单独回答链接由谁分享、传给了谁以及订单应归给谁。
一套可信的分享归因，需要把微信身份、业务分享凭证和转化事件连接起来。
一、从网页授权获取用户身份
在公众号网页场景中，常见授权链路如下：
- 用户打开页面，前端发现没有有效登录态；
- 服务端生成带state和回调地址的授权链接；
- 微信完成授权后，将一次性code带回预先配置的回调域名；
- 服务端使用code换取网页授权access_token和OpenID；
- 服务端将微信身份与自身账号建立映射，再向前端签发业务会话。
code、access_token和AppSecret都不应由前端承担长期保存或兑换。state需要与发起授权时的会话绑定并校验，用于降低请求伪造和流程串线风险。回调地址、授权范围及用户看到的页面，也必须与实际业务一致。
这张时序图的关键是分清前后端边界：浏览器负责跳转并携带一次性code，AppSecret和code兑换留在服务端；拿到OpenID后，系统还要签发自己的登录态。OpenID解决外部身份映射，不能代替业务账号和权限体系。
如果页面只需确认用户身份，可在接口允许的范围内选择更轻的授权方式；需要头像、昵称等额外信息时，应检查是否确有必要，并按当前平台规范和个人信息保护要求处理。拿到接口权限不等于可以无限收集。
二、OpenID和UnionID分别解决什么问题
OpenID是用户在某个应用标识范围内的唯一标识。它适合建立公众号、小程序等具体应用中的用户记录，但不应被称为全微信通用的“数字身份证”。同一个自然人在不同应用下可能拥有不同OpenID。
在满足微信开放平台绑定等条件时，UnionID可以帮助开发者在同一开放平台主体下识别同一用户，但它同样只是账号关联线索，不代表用户已经同意所有业务互通。系统仍需明确数据用途、访问权限和删除机制。
这组截图呈现了复制口令、好友打开和获得助力的完整体验，但它只能说明用户走过哪些页面，不能证明OpenID天然记录了传播关系。分享者与后续行为仍要靠独立的share_token和事件日志连接。
实际建模时，建议使用内部user_id作为主键，将OpenID、UnionID、手机号登录或App账号作为可变的身份凭证关联上去。这样可以处理换绑、注销、授权撤回和不同渠道登录，也避免业务表直接依赖外部标识。
三、分享归因真正依赖的是分享token
用户A点击分享时，服务端应生成一条分享记录，并返回随机、短期、不可预测的share_token。分享链接可以携带这个token，以及内容、章节或活动等必要上下文，但不应直接暴露完整OpenID。
接收者打开后，服务端记录token对应的访问事件；完成注册、激活或订单后，再按照既定规则连接转化事件。基本关系是：
分享者 → share_token → 点击会话 → 接收者账号 → 有效转化
token只能证明一次访问使用了某个分享入口，不能证明分享者与接收者之间存在好友关系，也不能证明对方一定看过某条微信消息。归因系统应如实记录能观察到的事件，不推断平台没有提供的数据。
为了防止改参数冒领奖励，token应由服务端生成和校验，并设置有效期、使用范围、签名或随机熵。订单退款、自买自推、老用户回流、多个推荐链接竞争等情况，要在活动开始前确定规则，而不是结算时临时解释。
四、进度同步和个性化承接
分享链接除了归因，还可以携带低敏感度的业务上下文。例如小说读到第二章后分享，接收者进入对应章节；课程学习者分享某节内容，好友先看到这节课的介绍；用户分享商品时，落地页保持同一SKU和优惠信息。
上下文应使用服务端记录的内容ID或短期状态，不在URL中暴露阅读历史、收益、手机号等隐私数据。分享者的“拉新战绩”也只向本人展示，不应将被邀请者身份和行为过度披露给分享者。
个性化的价值是减少重复操作，而不是利用OpenID进行隐蔽画像。需要跨场景使用数据时，应重新检查目的是否兼容、是否需要告知同意，以及用户能否关闭。
五、OpenID只是风控特征之一
同一OpenID短时发起大量邀请，或者多个账号围绕同一设备、支付工具和订单反复交易，可能是风险信号。但仅凭OpenID不能判断作弊，更不能把所有共用设备或网络的用户直接拦截。
风控应组合账号、设备、行为频率、订单、退款和关系结构等证据，按风险分级采取验证码、延迟结算、人工复核或拒绝奖励。若使用微信提供的安全能力，应以当前已申请并实际返回的接口字段为准，不能自行编造固定的风险等级。
这组页面说明了跨端关联的正确承接：微信登录只是身份确认入口，用户仍需明确选择账号和授权，才能把小程序、网页与App行为归到同一内部账号。关联应可查询、可解绑，不能仅凭相同身份线索自动合并业务账号。
评估归因系统时，除了统计点击和转化，还要观察重复归因、无效token、跨端丢失、退款回撤、申诉率和奖励差错。真正可信的归因，不是声称能看见完整社交链，而是清楚知道系统看见了什么、没有看见什么，并让每一笔奖励都有可复核的业务证据。