目标与背景
书院日常需要定期核查学生是否在寝，并开展宿舍卫生检查。面对多栋宿舍楼、体量较大的学生人数时，传统的逐间敲门点名、纸质登记和事后手工汇总非常耗时；再加上请假审批、签到异常申诉与卫生扣分分散在不同渠道处理，辅导员和学生干部核对起来很容易出错。
dormTK 的目标是把这些分散的寝室日常事务串成一套完整流程：学生在手机上打开微信小程序就能完成签到、出示查寝码或提交请假申诉；管理人员在桌面端集中审批和汇总记录，所有状态统一由后端服务校验与归档。
我的工作
我在项目中担任总技术负责人，负责整体架构设计，并统筹 Rust 后端、Slint 桌面管理端与微信小程序三端的开发协作。除了后端核心模块实现外，主要精力放在划清各端的业务边界、统一接口规范与数据模型上，确保学生在小程序里提交的每一条记录都能准确流转到管理端。
实现内容
学生侧日常事务
微信小程序首页直接展示当天的签到状态、所属寝室和常用功能入口：
- 在寝签到：读取手机周边的 WiFi 列表，与预先录入的寝室 WiFi 指纹做比对完成位置判定。
- 现场查寝确认：生成带有短时效限制的动态二维码，供查寝人员现场扫码核验。
- 请假与异常申诉：将“事前请假”与“签到异常补报”拆分为两条独立通道，支持上传证明图片并各自跟踪审批进度。
- 卫生检查记录：按寝室汇总历次卫生评分明细，方便学生随时查看，也支持检查人员现场录入结果。
多端架构与接口契约
后端采用 Rust 编写业务服务，搭配 PostgreSQL 持久化存储；桌面管理端使用 Rust 结合 Slint 构建轻量原生界面；学生端则落地在微信小程序。为了减少前后端联调时的字段歧义，项目通过共享的 Rust 数据结构自动维护 OpenAPI 接口契约，让桌面端和小程序都能对照同一份接口定义开发。
方案与取舍
在终端形态上，学生端最看重“随手可用”，微信小程序免安装、掏出手机就能扫码或签到，推广成本最低；而辅导员与宿管处理大批量审批、名单导出时更依赖键鼠操作和大屏视野，因此单独提供了原生桌面管理端，两端共用同一套后端服务与权限体系。
在核验机制上，没有把所有场景都押在单一技术上：日常自主签到用 WiFi 指纹降低打卡负担，面对面走寝则用短时二维码防代签截图；同时把事前请假和事后异常申诉拆开，避免正常的请假流程和定位偶发漂移的补救记录混在一起。
复盘与维护重点
做多端协作项目最大的体会是“状态定义必须先于界面开发”。小到一次签到的几种结果状态、一张申诉单的流转节点，只要各端理解稍有偏差，联调时就会返工。
此外，宿舍楼里的路由器变更会影响 WiFi 指纹匹配，二维码过期时间也需要在安全性与扫码体验之间平衡。实际运行中不能单凭某一次自动判定下死结论，把自动签到、现场核验和异常申诉结合起来保留人工复核余地，整套系统才真正落地可用。