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

先看两个真实场景
。

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

幼张，本科在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 —— 让每一个身份，都有？裳，始终如一
。