学校宿舍门锁的三个硬约束
校园项目和酒店、公寓都不一样，它有三个绕不开的约束：
- 规模大、变动集中：新生入学、毕业离校、宿舍调整都发生在几天之内，几千条权限要同时生效或失效。
- 不能靠学生自觉：钥匙丢失、私下转借、门不关是常态，必须有系统级约束。
- 要能出数据：归寝统计、晚归名单、异常开门，是学工部门真实的管理需求。
因此校园联网门锁方案的重点不是"能用手机开门"，而是批量权限调度与行为数据沉淀。
方案要点
| 环节 | 做法 |
|---|---|
| 开门方式 | 校园一卡通（IC / CPU 卡）、人脸识别、密码、手机小程序，可按楼栋组合 |
| 权限下发 | 按院系 / 年级 / 楼栋 / 房间批量导入，支持名单一次性写入 |
| 毕业回收 | 按批次注销，卡片同步失效，避免"毕业生还能开老宿舍门" |
| 归寝统计 | 按日 / 周汇总应到、实到、未归、晚归，导出交学工 |
| 异常告警 | 门长时间未关、非授权卡反复试刷、深夜高频开门 |
| 临时权限 | 维修、家长、检查人员按工单发放限时权限 |
联网方式怎么选：宿舍楼最适合 WiFi 直连
宿舍楼房间密集、层高固定、弱电条件差，最怕的是"每层都要布网关"。超低功耗 WiFi 联网门锁不需要网关，锁直接连云端，一栋楼只要每层有 WiFi 覆盖即可；对信号死角（楼梯间、地下室、老旧楼栋）用智能网关或蓝牙锁补位，形成混合组网。
断网时门锁本地保留已下发权限，刷卡、人脸、密码照常可用，网络恢复后补传记录——不会因为一次网络故障让整栋楼回不了宿舍。
与校园既有系统的衔接
- 一卡通系统：复用现有 IC / CPU 卡作为开门介质，学生不用多带一张卡。
- 学工 / 迎新系统：通过 API 同步新生名单与宿舍分配关系，自动生成权限。
- 门禁与梯控：门锁、门禁、梯控共用一套权限模型，避免"能进楼不能进房"。
接口能力详见 门锁 API 与二次开发。
隐私提示：人脸与开门记录属于个人信息，方案默认只采集开门必需的最小数据集（学号、时间、方式），人脸以本地比对为主、不必然上传原始图像；支持按校方要求做数据本地化部署。
实施节奏
- 锁体测绘与信号勘测（按楼栋抽样，通常 1～2 周）
- 试点楼栋上线，验证权限模型与统计口径
- 分批替换，寒暑假为最佳施工窗口
- 名单导入与培训（宿管、学工、信息中心三方）
- 验收：权限准确率、归寝数据完整性、断网可用性三项指标
常见问题
几千人的权限变更怎么批量处理？
支持按院系 / 年级 / 楼栋 / 房间批量导入名单，一次性写入生效；毕业、调宿按批次注销。开放平台同时提供批量下发接口，可对接校内系统自动触发。
能复用学校现有的一卡通吗？
可以。方案支持以现有 IC / CPU 卡作为开门介质，门锁侧读取卡号或扇区，不需要学生另带一张卡。
归寝数据怎么给学工部门用？
平台按日 / 周汇总应到、实到、未归、晚归，支持导出；也可通过 API 把数据回写到学工系统，由学校自行定义判定规则。
寒暑假施工来得及吗？
按楼栋滚动施工是标准做法，一个假期完成一栋楼到几栋楼的替换是常规节奏。建议先做试点楼验证，再在假期集中铺开。
学生把卡借给别人怎么办？
可开启刷卡 + 人脸 / 密码的复合验证策略；同时非授权卡反复试刷、深夜高频开门都会触发告警。