我们来聊一个底层架构问题：如果一个人的身份“断”了，数据怎么办？

先看两个真实场景。

场景一：本校升学的学生。

小张，本科在A大学读的，考上了本校的研究生。按理说，学校认识他、系统认识他、数据也认识他。但现实是——本科生身份到期，研究生身份新建。学号换了，账号换了，以前的借阅记录、获奖信息、一卡通流水，统统和新账号对不上。

“我明明在这所学校读了四年书，数据却像从来没来过一样。”

场景二：留校任教的博士。

杨老师，本科、硕士、博士都在同一所学校，最后留校任教。在传统身份体系里，她拥有了四个身份ID。更崩溃的是：新身份开户时，提示“身份证号已被绑定”——因为之前的身份已经占用了这个唯一标识。管理员得手动“解锁”，删除历史数据，才能让新账号用起来。

结果是：历史身份信息丢失了，人在同一所学校的完整生涯，被切成了互不相识的碎片。

这不是个别现象。据某高校统计数据，全校有近750人拥有多重身份，需要管理多套账号密码。 身份数据割裂，让每个多重身份者都成了“数字分身”。

当前：身份数据孤岛，让“认识你的人”变成了“不认识你的系统”

问题出在哪？

大多数学校的身份管理，是跟着“账号”走的，不是跟着“人”走的。

本科生有一个学号，研究生重新发一个学号，教职工再发一个工号。每个系统各自开户，各自记录。同一个人的三条身份轨迹，在不同数据库里是三个“不同的人”。

更麻烦的是GID的生成逻辑——很多学校原来的GID由一卡通系统生成。一卡通系统本来就不是为身份治理设计的，它管的是消费和门禁。数据治理缺乏统筹，久而久之，就出现了：一人多号、数据冲突、历史轨迹断裂、新身份无法绑定手机号和身份证号。

信息中心陷入一个尴尬的循环：有人反馈“新账号绑定不了手机号”→管理员手动改数据→删除历史身份信息→数据丢了→下次又来一遍。治标不治本，越治越乱。

产品支撑：SourceID 的GID全生命周期管理——为每个人配一把“终身钥匙”

针对这个痛点，SourceID 身份中台做了一件事：由身份平台统一接管GID的生成和管理，以一卡通等业务系统为身份源，采集人员数据，生成全校唯一的终身数字身份标识（Global ID，GID），并同步至全校数据库，确保数据准确性和唯一性。

旧流程 vs 新流程

GID 的核心逻辑

GID归并：从“账号绑人”到“人聚多账号”。

以身份证号为唯一标识，将同一个人在不同时期、不同角色的所有身份ID，全部聚合到一个GID之下。一个人只有一个GID，但这个GID下可以关联多个身份ID：本科学号、研究生学号、工号……

生涯全生命周期覆盖

入学/入职：系统自动为该人员创建GID，关联其初始身份（本科生/教职工等）。

升学/岗位变动：学生从本科升到研究生，GID不变。历史数据（借阅记录、获奖、成绩）自动关联到新身份，无需重复注册。教职工调岗、转岗，权限和身份状态按规则自动更新。

毕业/离职/合同终止：人员离校后，GID进入归档状态，身份状态自动失效，权限自动回收——时效从人工平均90天缩短至24小时内。

临时人员：增设有效期管控机制，到期自动注销，从源头杜绝僵尸账号。

权限管理的联动

GID不是孤立的ID，它是一把钥匙，撬动的是整个权限体系。

SourceID 结合RBAC/ABAC混合模型，基于GID实现智能权限管理：

精细化授权：人员身份状态一变（如从“在职”到“退休返聘”），权限自动调整，权随人动。

自动化权限回收：临时权限带有效期，到期自动熔断。

权限变更可追溯：每一次授权、回收、变更，都绑定到GID，全链路日志可查。

顺势认识一下 SourceID 的GID全生命周期管理

GID，不是一个新造的词。但把GID从一卡通系统的“附带品”变成身份中台的核心锚点，这件事的意义在于：

对用户：新身份来了，不用重新绑定手机号、身份证号，登录即用；完整的生涯数据连贯，可以查看自己的“全身份轨迹”。

对信息中心：不用人工改数据、删历史；数据准确、可信，GID作为身份锚点，为后续人员画像、数据服务、精准分析提供坚实底座。

对安全与合规：人员离校后权限24小时内自动回收，临时人员到期自动清理，审计可追溯——告别“人走了账号还在”的隐患。

GID管好了，一个人的数字身份才算真正“活”了起来。

它不是一串冷冰冰的编码，而是一个人在数字世界里从入学到毕业、从入职到退休、从临时来到按时走的全程见证。

SourceID —— 让每一个身份，都有迹可循，有始有终。