两套身份绑定为何互不相通：一次 OAuth 排查记录

背景

同一个用户，在两个相关的开发者实践平台上都能看到“已绑定 GitCode 账号”的提示，但其中一个平台的每日任务始终显示未完成。这类问题的难点不在操作，而在于先搞清楚：任务到底核查的是哪一份绑定数据。

一、先分清是哪一套绑定

很多实践中心各自维护自己的绑定表，即使它们都支持同一种第三方账号（比如 GitCode），数据也是互不相通的。A 平台显示已绑定，只能说明 A 的绑定表里有记录；B 平台的任务核查读的是 B 自己的表。如果不先确认这一点，就会出现“明明绑定了却一直不认”的错觉。

二、用接口判断状态，而不是看按钮

页面按钮的文案会受缓存、刷新时机和登录态影响，容易误判。更可靠的做法是直接读同源的绑定接口：返回结构里如果有对应 provider 的记录，并且状态是 bound，才算真的绑定成功。没有记录时通常返回一个空的绑定数组，这个差异非常明确。

三、OAuth 完成后要刷新状态

授权流程本身很快：请求授权地址、跳转到第三方、点授权、回调返回。但回调那一下有时会出现一次性的 500，页面上看起来像失败。此时不要重复授权，直接再读一次绑定接口即可确认结果。另外，绑定完成后页面上的按钮文案通常要刷新一次才会更新，这也是“看起来没生效”的常见来源。

四、核查结果里的 progress 才是真相

任务提交接口一般会返回一个 progress 对象，里面有当前识别到的第三方账号、命中的仓库列表、缺失的匹配条件等字段。比如看到缺失项是一个组织条件、命中列表为空、最近一次星标时间为空，就能判断是核查侧没有读到数据，而不是用户没有操作。把这些字段记录下来，比反复点击“去完成”有效得多。

小结

跨系统的身份绑定排查，顺序应该是：先确认是哪一套数据、再用接口确认绑定状态、最后看核查返回的明细。把每一步的证据留存下来，问题定位会快很多。