住宿的一生预分配调宿退住

明·如归 · 宿舍管理白皮书 ｜ 第二篇 能力篇

第九章讲完了床位的静态结构——层级、并发保护、三条不可配置的规矩。但床位的使用不是拍照定格的。从八月把新生的名字挂进批次，到次年七月最后一个毕业生把钥匙交到前台，一张床在十个月里被不同的人占住、换出、空出来再填满——每一次变动都是一条有因果、有审批、有痕迹的事件。 把它们串起来，才是"住宿的一生"。\u8fd9\u6761\u65f6\u95f4\u8f74\u4e0a\u7684\u4e8b\u60c5——批次化分配、审批链调宿、带快照的退住归档。

11.1 分配不是按一次按钮：五步批次流程

多数学校的新生分配曾经是一天的事——机房里几台电脑、一个导数据的脚本、一个跑完就丢的中间表。系统把这件事拆成了五个可暂停、可回退、可复核的批次步骤：

第一步，建批次。 指定名称、学年、参与分配的学生范围（按年级、学院或手动勾选）。批次一旦建立，后续所有操作都挂在它下面——谁分到了哪、规则是什么、分了几轮——都有归属。

第二步，圈定房源池。 哪些楼栋的哪些床位对本次分配可用；已有人在住的自然不在其中。这一步决定了分配的输出不会"撞到"现有住户。

第三步，导入或同步名单。 手动导入走模板校验（第七章那条通道），从教务同步走对账引擎。不管哪条路，进入批次之前先确认"这个人有合法床位需求"。

第四步，设定分配规则。 这一步决定了自动分配的行为——下一章单独展开。

第五步，执行与导出。 执行结果落库；导出给院系一份名单、给宿管一份按房间排列的钥匙清单。

五步的任何一步都可以停下来重来，重来不产生双份数据。 分配不是一锤子买卖，是一次可以被打断、被检查、被追加的事务。已经分好的学生不会被第二次执行覆盖——"不覆盖已有分配"是批次执行的一条硬规则：只有尚无床位的人参与本轮。

11.2 混编规则：六个开关与一条不覆盖

分配规则的核心是六个布尔开关：按学院集中、按专业集中、按班级集中、按民族集中、按国籍集中、按服兵役集中。每所学校可以任意组合——"同班集中但不限民族"或者"不分学院只分性别"。规则写进批次，不是一次执行完就消失——它跟着批次持久保存，追加分配时自动沿用同一套约束。

六个开关之外，规则表还可以按院系和专业设配额——某学院限分哪几栋楼、某专业预留哪些房间。配额百分比、优先级、生效范围，都是管理员在规则页面配的，不找开发。

11.3 调宿：一场三方利益的审批链

开学一个月之后，调宿申请就来了。原因五花八门：和室友处不来、身体原因需要低楼层、专业调整要换到本学院集中区。不管原因，流程是同一套——申请提交、逐级审批、执行变更、记录归档。

审批链的级数由学校配置：可以简单到"辅导员一审"，也可以复杂到"院系 → 宿管中心 → 后勤处"三级会签。系统支持三种审批模式——依次审批（N 个组按顺序全部通过才算过）、或签（任一审批人通过即生效）、会签（所有组都有人通过才算过）。三种模式共用一套数据结构：每条审批记录带角色组、审批人、时间、结果和备注，形成完整的流程链。

调宿最怕的不是审批慢，是批了执行时出事。 两人互换是一种常见操作，但如果旧床位释放和新床位占用拆成两步执行，中间断电或接口异常就会出现"两个人同时没床"的半截子状态。系统的做法是把换床当成一个事务：要么两个人都到了新床，要么两个人都留在原位——中间态不允许存在。

还有一种边界：调宿审批通过后，目标床位在等待执行的那几天被人占了。系统在落库前再查一次目标床位是否空闲——不通过则驳回并说明原因，不让人因为"批了但执行不了"陷入更尴尬的境地。

11.4 退住：人走了，记录留下

毕业、退学、出国、转走读——原因不同，动作相同：释放床位、归档记录。

系统的退住处理有一个容易被忽略的设计：不清除床位编号。 退住后，原来的分配记录把状态标记为"非在住"、把人员关联解绑——但床位号、房间号、入退时间全部保留。"他在这里住过"这个事实不会因为人走了就变成空白。

每一条退住操作同时生成一条住宿变更记录，带着\u64cd作前快照——房间、床位、学院、操作者、时间戳，完整留底。批量退住和导入退住走同一逻辑，每条记录各自有快照。

给一个场景：毕业三年后某学生的住宿记录有争议（学校需要出具"他确实住过几号楼几号床"的证明），打开那条退住记录，快照里房间号和床位号还在。 如果系统只留了"在住名单"而删了退住数据，这件事就没人能证明。

数据留存不是技术洁癖，是对将来那个需要追问的人负责。

11.5 走读：安全责任的交还

走读申请在调宿链上最特殊。它不是"换一张床"，是"从住校变成不住"——意味着学校把夜间安全的一部分责任交还给家庭。所以它的审批链比调宿更长、确认环节更重：家长联系方式与确认是流程的硬组成，不能只凭学生自己点一下。 走读生效后，考勤不再产生该生的未归记录——他在"在住名单"里消失了，自动考勤的第四层排除自然把他过滤掉。

11.6 记录全景：三种类型一条线

住宿记录的终态被系统归纳为三种操作类型——入宿、调宿（含换宿）、退住。这三种覆盖了一个人从第一次拿到钥匙到最后一次交还的全部变动。每种类型都可按楼栋、按学院、按时间区间检索和导出。

统计接口把入宿数、退住数和调宿数按月度汇总，喂给管理端的数据动态看板。一张床在一年内被换了多少次、哪栋楼的调宿率最高、退住集中在哪个月——这些数字是宿舍管理的体检报告。

11.7 给学校的一件事

期末前翻一翻本校的住宿变更日志——从本学期随机挑五张换床单子，看每一张能不能当场回答四个问题：谁发起的、谁批的、哪一秒生效的、原来那张床现在住着谁。 四问都有干净答案，住宿全生命周期这条链就算闭合了。

分配管住了"从哪里来"，调宿管住了"怎么变动"，退住管住了"到哪里去"。这三段连起来，一个学生从大一拿钥匙到大四交钥匙的住宿一生，每一步都有据可查。下一章要谈的是住在这段日子里天天碰到的事——查卫生、打星级分、东西坏了找谁修。