排班查询
正在加载学期信息...
先点选上方某个节次，再开始查询。默认会智能使用系统极速缓存。
运维与设置
批量导入成员数据，检测账号连通性。
总成员数
0
测试正常
0
测试异常
0
批量导入成员
格式：姓名,部门,账号,密码。换行分隔。院系班级在后续测试中自动补全。
手动补录单个成员
系统成员名册
系统原理
只说明这套系统如何通过教务接口获取课表并生成空闲名单。
内部说明
这套系统主要是通过整理学校教务接口，获取成员课表后再统一生成空闲查询结果。
系统不会直接读取学校数据库，而是通过已经存在的教务接口完成登录、学期识别、周课表读取， 最后根据选中的周次、星期和节次，判断每个成员在该时间段是否有课。
核心方式
逆向整理教务接口
主要结果
批量空闲名单
判断依据
周次 + 星期 + 节次
一、基本流程
01
保存成员账号
先录入姓名、部门、账号、密码，作为后续统一查询的基础。
02
登录教务接口
使用成员自己的账号密码调用登录接口，换取访问令牌。
03
读取学期和课表
先获取当前学期与当前周，再读取指定周的个人周课表。
04
生成空闲结果
按选中的星期和节次判断谁有课、谁没课、谁账号异常。
二、逆向得到的核心接口
POST /admin-api/system/auth/login：登录并获取访问令牌GET /admin-api/campus/semester/current：获取当前学期、当前周等信息GET /admin-api/campus/student/getByUserId：获取学生基础信息GET /admin-api/campus/myclassschedule/getMyClassSchedule：获取指定周的个人课表
这些接口经过整理后，被后端统一封装成适合批量查询的流程，而不是只供单个人查看课表。
三、接口调用方式
系统后端调用教务接口时，主要按照下面的顺序执行：
- 先用账号密码调用登录接口，获取
accessToken - 请求头带上
Authorization: <accessToken> - 同时保持
source-client: app这一请求头 - 先获取当前学期，再按周次读取课表
也就是说，这套系统本质上是把原本分散的几次请求串起来，形成一条固定的数据读取链。
四、空闲判断是怎么做的
系统拿到某个成员的周课表后，会把每节课整理成统一结构，再和当前筛选条件比对。
- 如果课表里存在“对应周次、对应星期、对应节次”的课程，则判定为忙碌
- 如果不存在对应课程，则判定为空闲
- 如果登录失败或接口异常，则单独归类为异常账号
最终页面展示的结果，就是空闲、忙碌、异常三类名单。
五、系统里实际保存的数据
- members：成员姓名、部门、账号、密码、状态信息
- schedule_cache：某成员某一周已经读取过的课表缓存
这样做的目的，是避免每次查询都重新把所有成员从零开始拉一遍课表，提高速度。