- 退住需六张表在同一事务内联动，不可出现半更新状态
- 批量退住按学院年级筛选一次落库，失败记录明确列出不静默吞掉
- 离校在住质量规则可防止幽灵床位与门禁安全隐患
- 毕业生数据封存可由学校选关闭、只读档案或完整保留三种政策
- 退住后数据继续用于统计、审计追溯与下一届政策反哺
明·如归 · 宿舍管理白皮书 ｜ 第五篇 旅程篇
六月的最后一天，李洋把最后一箱行李搬出 512。陈昊站在门口看着他、递过来一瓶矿泉水——四年前那个 22:00 就熄灯的年轻人已经变成会熬夜陪室友改简历的人了。李洋把钥匙放在窗台上、拍了一张空房间的照片——这是他在这套系统里留下的最后一条动作。
"离开"在系统里长这样——退住的执行、数据的封存、画像的完结、毕业之后系统还能做什么。展开讲七件事。
28.1 退住不是"清空房间"，是六张表的一次联动
李洋在移动端提交退住申请、或者辅导员批量给整个毕业班发起退住。系统内部六张表同时联动：
- 住宿记录：状态从"在住"切"已退住"；这条记录永久保留，带原始分配时刻与退住时刻；
- 床位：状态从"占用"切"空闲"；床位归属保留（还挂在 512 3 号床上）；
- 房间容量：已住人数从 4/4 变 3/4；
- 考勤日历：从退住次日起，李洋不再进入考勤范围——不删除他以前的记录、不新增他的记录；
- 设备权限：门禁卡自动作废、下次不能刷开 3 栋的门；这一步走设备连接器；
- 画像：住宿画像的"当前在住"字段清空、"历史住宿"字段追加一条完整记录。
这六张表在同一个事务里改齐——不会出现"住宿退了、门禁还能刷"、"床位空了、考勤还在算他"这种半更新状态。这套系统对"退住"的严谨度跟"入住"一样：一次入住登记错了可以补、一次退住做错了可能引发安全事故（毕业了两年的学生还能刷开宿舍门）。
28.2 批量退住：整建制毕业的一次操作
每年 6 月底，学校要给两三千名毕业生一次性退住。这套系统对这个动作有专门的路径：
- 管理员在管理端按"批次 / 学院 / 年级 / 专业"筛选出目标学生名单；
- 选一个执行日期（"2029-06-30"）；
- 点击"批量退住"——系统按筛选结果生成 N 条退住记录，一次落库；
- 每条记录都带来源（"批量操作"）、操作者、时刻、依据；
- 执行结果输出：成功多少、跳过多少（已经不在住的）、失败多少（并发或其他原因）。
关键的一条：失败或跳过的记录会明确列出，不静默吞掉。这样管理员能立刻看到"哦，这 8 个人原来上个月已经办了退住"，不会以为"操作失败"。
批量退住不是"删掉一批人"——是把一批人从"在住"切到"已退住"，所有历史记录完整保留。
28.3 数据封存：毕业生能看到什么、看不到什么
李洋毕业五年后想查自己当年住哪间房、和谁住——这件事系统对毕业生是否开放，由学校定。三种典型政策：
- 完全关闭：毕业即注销账号；他查不到任何东西。这条路最简单、也最浪费——五年积累的学生生活数据就此与本人断联；
- 只读个人档案：毕业生可以登录、只能看自己的住宿记录、考勤、检查、报修、请假——看不到别人的信息、看不到统计报表。这一条是最推荐的，因为它把系统作为"你自己大学四年的完整住宿档案"留下来；
- 完整保留：毕业生账号能进系统、能看到自己所有相关记录 + 同学的名字（不看到同学的当前状态）。
这套系统对三种政策都支持——权限模型和"角色 → 用户组 → 成员"挂接足够灵活，把"毕业生"设成一个只读角色即可。具体选哪种，是学校自己的政策决定。
28.4 住宿画像的最后一笔：四年完整档案
李洋毕业后，他的住宿画像在系统里最终形态是：
- 基础信息：学院、专业、班级、入学与毕业日期；
- 住宿变更：四年里的所有分配 / 调宿 / 换房记录，每一条带原因与操作者；
- 考勤汇总：四年里的在寝 / 迟归 / 未归 / 请假总天数与关键节点；
- 检查与评级：宿舍卫生检查的每学年平均分、Top / Bottom 记录；
- 报修汇总：他提交过的报修工单数与主要类别；
- 宿舍活动：如果学校配了活动数据，可以挂进来。
这份画像是他大学四年"生活"这一维度最完整的档案。学校可以把它做成"离校报告"的一部分、可以在他自己申请时导出成 PDF 给他——这是这套系统对毕业生最有温度的一件事。
28.5 离校未退：那条最容易被忽略的质量规则
毕业季最常见的一件事是"学籍毕业了但床位还挂在'在住'状态"。这可能有两种原因：
- 学生延期毕业，实际还在住——学籍状态切"离校"是错的；
- 学生已经离校、退住流程忘了办——数据滞后。
这套系统的五条质量规则里，"离校在住"就是专门查这一件事：定期扫"学籍状态 = 毕业 / 退学 / 休学 且 住宿状态 = 在住"的学生，落到问题工作台由管理员核实。
这一条规则的另一个名字叫"防止幽灵床位"：一个学生已经毕业两年、床位还挂"在住"——下一届新生分房时这张床就被"看不见"占用了；一个学生已经退学、门禁卡还能刷开宿舍门——这是安全事故。这两件事都靠"离校在住"扫描 + 定期处理避免。
28.6 退住之后：数据还能被谁用
毕业生走了，他的数据在系统里继续做三件事：
- 统计：某学院历年床位周转、某楼栋入住曲线、某年级异常趋势——这些统计要包含历史毕业生，不然口径不完整；
- 审计：教育评估、专业认证、上级检查——要能追溯"这届毕业生四年前是怎么住的"；
- 反哺：下一届的分配政策、宿舍翻新计划、检查评分标准——都是从往届数据里长出来的。
这三件事的正当性支撑"数据不能因为本人毕业就删掉"这条纪律。学生离校不等于学校对他的数据控制变成非法——只要还在"办学必需"的用途范围内、就属于合理处理。这一条在《个人信息保护法》"履行法定职责"的合法性基础里有对应条款。
28.7 给学校的一件事
毕业季前一个月，问你的信息中心或宿管中心："我们上一届毕业生里，有多少人的住宿状态到今天还挂在'在住'？"
如果答案是"没统计过"——你的质量规则里"离校在住"没在跑。开起来。
如果答案是"20 个人、我们都联系过、他们同意了"——那这些人可能是"学位延期"或"论文二辩临时留宿"，让他们继续"在住"是对的；系统里给这条状态加一个可解释的字段（"延毕留宿"）就完美了。
如果答案是"100 多个人、也没人管"——这就是典型的"毕业即失控"。门禁卡没作废、床位被幽灵占用、审计来了说不清。这一件事不需要重新分房、只需要一次批量操作就能清理——但学校要记得做。
李洋把钥匙放在窗台上、走出 3 栋。系统没有弹出什么庆祝动画，也没给他发一句"祝前程似锦"——它只是安安静静在系统里把那条住宿记录从"在住"切到了"已退住"，从此不再动。这份安静就是这套系统对毕业生能给的最好的告别：你在的时候我认真记，你走了我不打扰，你五年后想回来查，我随时开门。