考勤这件事很多高校课堂和培训机构到现在还停留在“花名册点名”或者“签到表传一圈”的阶段麻烦不说课后统计出勤率更是灾难。我最近完整梳理了一套跑通的课堂考勤签到系统基于Java SpringBoot技术栈覆盖了课程管理、学生签到、教师考勤统计、请假审批、导出报表这些核心功能。这篇文章不是给你复述一遍需求文档而是把我在实际设计、开发、调试、部署这套系统的过程中觉得真正值钱的思路和踩过的坑讲透包括功能怎么拆、数据库怎么建、签到防作弊怎么做以及配套的LW设计文档、调试文档、讲解资料到底怎么用。如果你正在用SpringBoot做课程设计或毕业项目或者想给实验室、培训班搞一套轻量考勤工具可以重点看第2、3、5章可以直接照着落地。1. 项目定位与整体设计思路1.1 这类系统到底在解决什么痛点先说清楚课堂考勤场景里的三个老大难问题。第一是效率问题。四五十人的课堂传统点名至少花两分钟如果碰上老师习惯逐个核对脸五分钟就没了。一学期下来光点名消耗的时间非常可观。二维码签到或者GPS定位签到可以把单次点名压缩到十几秒。第二是统计问题。纸质签到表收上来之后课代表要在Excel里手工录入谁来了、谁没来、谁请假中间只要抄错一个名字期末成绩的平时分就可能出岔子。更麻烦的是如果想按周、按月或者按单个学生维度归纳出勤趋势手工统计几乎会让人崩溃。第三是代签和流程闭环问题。纸质签到表传一圈总有人“顺手帮室友签一下”老师事后也无从查证。请假流程更是断裂——学生口头跟老师说一句就算请假但考勤记录里没有任何体现期末核算时说不清楚。所以考勤系统的本质不是“把签到表做成网页”而是把签到动作、防作弊规则、请假审批、数据统计全部在一个闭环里管理起来。标题里反复出现的课堂考勤系统、考勤签到系统、课堂签到系统其实都是这套东西的不同叫法底层逻辑完全一致。1.2 为什么技术栈选了SpringBoot而不是其他方案现在Java Web项目选型SpringBoot已经成了事实上的默认选项。原因很直接它把过去SSM阶段那些繁琐的XML配置基本干掉了一个启动类加几个注解就能把Web容器、Spring容器、数据源这些都串起来。拿这批代码实际的组成来说大致是这样Spring Boot负责整体框架和自动配置MyBatis-Plus负责数据库操作代码生成器和条件构造器能省掉大量CRUD的重复劳动Spring Security或者简单的JWT拦截器负责登录鉴权区分学生、教师、管理员三种角色MySQL存业务数据Redis用来存签到二维码和短期热点数据前端这块如果用前后端分离可以选Vue如果图省事直接用Bootstrap Thymeleaf也完全够用。为什么不用SSH或者纯Servlet对于课堂考勤这类中小型系统SSH太笨重Servlet太原始。考勤系统的并发量通常很低核心诉求是开发效率、易维护性、好调试SpringBootMyBatis-Plus的组合几乎是这个量级项目里最顺手的搭配。我记得早期有一个版本的签到功能用的是HttpSession存登录状态后来改成JWT之后前后端联调就舒服多了移动端扫码那块尤其明显不需要考虑Session跨域问题。1.3 用户角色与权限边界怎么划考勤系统最常见的角色有三种学生、教师、管理员。角色设计如果一开始没想清楚后面每个接口都得返工。学生端看到自己已加入的课程进行签到、请假查看自己的考勤记录和出勤率统计。教师端创建课程、发布签到任务、设置签到有效时间或位置围栏实时查看已签/未签列表导出统计数据。学生请假也归教师审批。管理员端维护学院/班级基础信息、管理教师和学生账号、查看全局考勤数据概览。通常管理员不需要掺和到具体某节课的签到里。权限边界上最容易犯的错是把“查看”和“操作”混在一起。比如学生理论上不应该看到某个课程的全部学生考勤明细但有些设计里为了偷懒一个接口把整张表的数据都返回了这既不安全也不合理。我当时的做法是Controller层每个接口都通过注解或拦截器拿当前登录用户的角色和ID然后在Service层强制校验数据归属。例如查询考勤列表时不仅要传courseId还要确定request里的userId是这门课的教师否则直接抛出无权限异常。这套逻辑一旦在早期就固定下来后面加功能会省心很多。2. 核心功能设计与实现要点2.1 签到方式的取舍二维码、GPS、普通签到目前主流课堂考勤系统包含三种签到方式各有优劣最好都支持让教师按场景选。第一种是普通签到学生登录后在“当前进行中的签到任务”里点一下按钮。开发最简单但防代签能力为零。适合人数少、老师熟悉学生脸的小班课。第二种是二维码签到教师端点击“开始签到”后端生成一个随机码前端通过二维码组件渲染成二维码投在屏幕上。学生扫码后识别出签到Code传给后端完成签到。这里的关键是二维码要带过期时间通常60~120秒刷新一次否则学生把码拍照发给没来的同学这个机制就废了。第三种是GPS定位签到教师创建签到时设置一个经纬度坐标和允许偏差范围比如半径100米。学生签到时前端通过浏览器或App拿到当前经纬度和后端计算距离超过阈值就拒绝。这个方案能防止人不在教室但扫码的情况但受GPS漂移影响误差调太严容易误伤调太松又形同虚设。三种方式横评可以参考下面这张表签到方式开发难度防代签能力适用场景备注普通签到低几乎为零小班型、老师能认全人实现最简单二维码签到中中大部分课堂需配合过期时间GPS定位签到中高较高固定教室/实验室需合理设定误差半径我在实际项目里是三种都做了后端对应三个接口核心的签到记录表结构完全复用只是来源字段标识是QUICK、QR_CODE还是GPS。这种做法后期统计非常方便按来源分组就能看出哪种方式使用得多。2.2 教师端工作流从创建课程到发起签到教师端是考勤系统的“发动机”流程设计得顺不顺直接决定教师愿不愿意用。基本流程是这样的教师登录后先创建课程填课程名称、上课时间、授课地点这些基础信息。然后从学生列表里勾选或按班级批量导入学生建立课程和学生的关联关系。这一步特别重要因为后续签到记录必须落在“某个学生 某门课程”这个维度上没有选课关系考勤数据就没有归属。发起签到时教师选择课程设定签到类型普通/二维码/GPS、签到有效时长、是否需要定位校验。后端会生成一条AttendanceTask记录状态为进行中。学生端通过轮询或者WebSocket推送看到新任务就能开始签到。这里多说一句如果不想引入WebSocket最简单的方式是学生端进入课程页时主动刷新任务列表或者用前端setInterval每15秒请求一次课堂场景几十个人同时轮询服务器毫无压力。签到结束后教师可以进入课程详情页看到实时统计的应到、实到、请假、缺勤人数也可以按学生逐条查看签到时间和位置。导出功能我是用EasyPOI做的一键导出Excel列包括学号、姓名、签到状态、签到时间、签到方式期末核算平时分时直接拿去用。2.3 学生端和请假审批的闭环设计学生端功能看着简单但有一个容易忽略的点签到状态展示要足够清晰。我按“课程列表 → 某门课详情 → 今日签到状态”三层来组织。课程列表页显示所有已加入的课程以及最近一次考勤的概要结果比如“已签到”“缺勤”“待签到”。进入详情页后学生能看全部历史考勤记录和出勤率界面上用一个进度条直观显示到课情况。请假功能必须和签到联动否则考勤统计就是一笔糊涂账。我的做法是学生提交请假申请时选择课程和请假时间段附上事由说明。教师端收到待审批请求通过后后端自动在对应时间段内生成一条“请假”状态的考勤记录。这样期末统计时“出勤”和“请假”分开计算学生不会因为请假被误判为缺勤。这里最关键的体验细节是防重复提交。学生点“签到”之后前端要立刻置灰按钮后端在接口入口做幂等判断查询同一课程同一学生是否已有有效签到记录如果有就直接返回成功而不是报错。否则网络慢的情况下学生双击按钮就会生成两条记录统计时如果忘了去重出勤人数就会虚高。2.4 数据统计与导出背后的口径问题统计模块最容易被低估。很多初版代码只是简单用一个count数一下出勤人数但真实需求往往是多维度、多条件的。我在做统计时定义了三个核心口径出勤率实签人数 /应到人数 - 请假人数这个口径认可度比较高因为请假属于正常情况缺勤率缺勤人数 / 应到人数缺勤包括未签到且未请假的情况补签率补签次数 / 总签到次数这个指标用来观察学生是否频繁依赖补签通道。统计维度至少要支持按课程、按班级、按周、按单个学生四种视角。页面上一开始不要全堆上去先展示最常用的“课程出勤率趋势”其他维度做成可折叠的高级筛选。数据量不大时直接在MySQL里用GROUP BY查就行不需要引入OLAP引擎但如果期末要按整个系部汇总最好在Java代码里做一次缓存避免每次打开页面都重新计算。3. 数据库设计与接口关键实现3.1 核心表结构是怎么设计的数据库设计决定了整个系统后面能走多远我建议至少包含以下六张核心表user表用户基本信息区分学生/教师/管理员course表课程信息student_course表学生选课关联表这是学生和课程的多对多桥梁attendance_task表教师发起的每一次签到任务attendance_record表学生每一次签到的明细记录leave表请假申请记录。有人可能问为什么不把任务和记录合并成一张表。我实际对比过合并表做开发期看起来简单但统计时特别痛苦。比如查询“某次签到的应到人数需要count这门课关联的全部学生”如果合并了就得先distinct学生再去重。任务表和记录表分开的好处是任务表存“教师发起签到这个事件”记录表存“学生对这个事件的响应”职责清晰index也容易建。attendance_record表里有一个很核心的字段叫status我用的是TINYINT类型0缺勤、1正常、2迟到、3请假、4补签。这里面补签是个特殊状态表示学生没赶上正常签到窗口后来申请并获得教师同意后的记录。如果你想把业务做得细一点还可以加一个sign_type字段区分签到方式再额外存经纬度和签到设备信息这些都是合规范围内可以记录的数据。3.2 签到接口的幂等与并发处理签到接口是系统里并发压力最集中的地方虽然几十个人同时点也不至于把服务器打挂但代码层面的并发控制必须做对否则会出现脏数据。先说幂等。我的处理方式是“先查后插 唯一索引兜底”。在attendance_record表上加一个联合唯一索引 (task_id, student_id)这样即使前端重复提交了两次请求第二次插入时数据库会因为唯一索引直接报错我在代码里捕获DuplicateKeyException并转成“签到成功”返回。这个方案比单纯用Redis分布式锁轻量得多也更稳。再谈金额或者积分这种并发场景在这里不适用但有一个数据竞争的典型案例学生同时用两台设备登录一个走GPS签到一个走二维码签到最终可能生成两条记录。解决方案也很简单在Service层进入时先检查该学生当天这门课是否已有状态为“正常”或“补签”的记录有就直接返回已有记录。代码大致长这样public AttendanceRecord signIn(SignInRequest req, Long studentId) { // 幂等校验同一签到任务下只允许一条记录 LambdaQueryWrapperAttendanceRecord wrapper new LambdaQueryWrapper(); wrapper.eq(AttendanceRecord::getTaskId, req.getTaskId()) .eq(AttendanceRecord::getStudentId, studentId); AttendanceRecord exist attendanceRecordMapper.selectOne(wrapper); if (exist ! null) { return exist; } // 校验签到时间是否在任务有效期内 AttendanceTask task attendanceTaskMapper.selectById(req.getTaskId()); LocalDateTime now LocalDateTime.now(); if (task.getEndTime().isBefore(now) || task.getStartTime().isAfter(now)) { throw new BusinessException(签到已结束或未开始); } // 走GPS时校验位置偏差 if (task.getType() 2) { double distance DistanceUtil.distance(req.getLat(), req.getLng(), task.getLat(), task.getLng()); if (distance task.getRadius()) { throw new BusinessException(当前位置不在签到范围内); } } AttendanceRecord record new AttendanceRecord(); // ... 填充字段 attendanceRecordMapper.insert(record); return record; }这段代码里能看到一个容易被忽略的点签到时间校验要在记录插入之前做。有同学把校验放在插入之后那等于没校验数据已经写进去了后面改状态反而麻烦。3.3 二维码和GPS定位背后的算法细节二维码这部分后端逻辑其实不复杂生成一个随机8位字符串存到Redis并设置过期时间然后把它编码成Base64返回给前端展示。学生提交二维码内容时后端拿着内容去Redis里查查到了并且是当前有效的那一批就放行。需要注意的坑是不要用固定的字符串当二维码内容那样明显可以被伪造也不要只用UUID因为扫码工具会把UUID当成文本而不是URL。常规做法是生成一个短ID作为签到码前端拼上一个固定的路径前缀渲染成二维码。这样学生扫出来是一个带业务参数的URL既有辨识度也好排查问题。GPS定位这部分后端用到的核心算法是球面距离计算。大多数人写的是Haversine公式我直接封装成一个工具方法。实际使用中要特别留意的是前端传上来的经纬度精度和坐标系问题。国内手机浏览器默认返回的是GCJ-02坐标系如果你拿它和地图API上的坐标直接套公式算距离可能差几百米。稳妥的做法是后端统一用WGS84坐标系计算前端拿到坐标后先做坐标转换或者在后端同时保存原始坐标和转换后坐标方便排查误差。偏差阈值怎么定我给出一个经验范围普通教室场景半径建议80~120米体育馆、操场建议150~250米。我自己踩过的坑是把半径设成20米结果一个靠窗坐的学生因为GPS漂移死活签到失败后来放宽到100米就正常了。位置校验的目的是防“人在宿舍签教室的到”不是精确到座位阈值宁大勿小。3.4 时区与时间边界问题如果后端部署在国内服务器基本不会遇到时区问题但如果你本地开发时把数据库连接串里忘了加serverTimezone参数或者服务器设在海外就可能遇到签到时间整整差8小时的情况。我处理时统一在JDBC连接串里加参数jdbc:mysql://localhost:3306/attendance_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai同时数据库表里的时间字段统一用DATETIMEJava实体类里统一用LocalDateTime不要混用java.util.Date和Timestamp否则序列化到前端时格式会很乱。判断“今天是否有签到任务”时用LocalDate.now()去比对日期字段就好别直接拿时间戳去截断处理起来又麻烦又容易差边界。4. 从零跑通环境搭建与实操运行4.1 开始之前你需要准备什么如果你拿到的是一整套源码加文档动手前最好花几分钟把环境理清楚这事比想象中重要。我们的项目是基于以下这套环境跑的建议你尽量贴近JDK 1.8或11不要用最新的JDK 21去跑老项目容易碰到兼容问题Maven 3.6IDEA建议2022以后版本MySQL 5.7或8.0注意8.0的认证插件和驱动版本差异Redis 5.0如果二维码签到和缓存功能依赖Redis的话Node环境仅当前端需要打包时用如果项目是Thymeleaf模板就不需要了。代码导入IDEA之后第一步先让Maven把依赖拉下来。这一步在网速不好时可能很煎熬。我建议你配置阿里云镜像在Maven的settings.xml里加mirror节点否则某些依赖下载半天然后失败纯浪费时间。4.2 配置文件里最容易改错的地方项目的核心配置集中在application.yml或application.properties里。你需要重点看这四块内容server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/attendance_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 timeout: 3000ms mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto新手最容易在这里犯两个错。第一个是MySQL密码没改直接用了文档里的示例密码结果启动时报Access denied。第二个是Redis没启动就急着启动项目日志里跳一堆连接异常。这里要特别强调如果你的系统里Redis只用来做二维码缓存那么Redis没启动时项目本身可能不报错但签到功能一定失败调试时第一反应先去看redis-server进程在不在别一头扎进代码里找问题。4.3 建库建表和初始数据源码包里一般会附带一个sql脚本文件类似attendance.sql。运行之前先手动创建一个空的数据库然后在命令行里执行mysql -u root -p source /path/to/attendance.sql;或者直接用IDEA的Database面板右键运行整个SQL文件更直观。SQL脚本里除了建表语句通常还会预置一些演示账号比如管理员/admin123教师/teacher123学生/student123。这些账号在调试阶段非常有用不用自己注册就能直接测功能。等你能正常登录了再考虑改成自己的账号体系。4.4 调试文档的正确打开方式很多人拿到调试文档只看“启动步骤”然后一路按回车其实调试文档里最有价值的部分是那张“常见错误对照表”。我看到大部分项目的调试文档里都会总结这么几类问题端口被占用把8080改成8081改完要确保前端页面配置的路由或代理也跟着改数据库字符集不是utf8建库时如果没有指定字符集中文可能变成乱码前端静态资源加载不出来通常是Spring Boot对静态资源的静态路径配置不对或前端资源没有放到resources/static下面。调试文档里如果给了自测接口列表建议照单全收地测一遍。比如登录接口、签到接口、请假接口这些是主链路任何一个接口出问题都要优先排查。我习惯每次改完代码后把主链路重新点一遍确认没问题再改下一块而不是憋到最后一起测不然出错时根本定位不到是哪次改动引入的。5. 常见问题与排查技巧实录5.1 时区问题签到时间差8小时我曾经在一台新配置的测试服务器上部署发现学生签到后记录的时间比实际晚了8个小时。排查一圈发现数据库连接串里没有指定serverTimezone而服务器操作系统时区是UTC。解决方式有两种改连接串或者改MySQL全局时区。建议优先改连接串jdbc:mysql://localhost:3306/attendance_db?serverTimezoneAsia/Shanghai同时检查Java运行环境的时区可以在启动参数里加 -Duser.timezoneAsia/Shanghai。改完之后重启服务重新签到一条测试记录确认时间正常再继续。经验之谈只要是部署到云服务器第一件事就是检查系统和数据库时区越早发现越省事。5.2 Maven依赖冲突版本不对导致启动失败项目如果引入了较老的MyBatis-Plus版本和Spring Boot 2.7.18有一些默认依赖冲突症状是启动报NoSuchMethodError或者Mapper扫描不到。排查思路先确认自己项目的Spring Boot主版本再确认MyBatis-Plus的兼容版本。通常情况Spring Boot 2.x对应MyBatis-Plus 3.5.xSpring Boot 3.x要对应MyBatis-Plus 3.5.3以上。如果依赖冲突很顽固我建议直接在IDEA的Maven面板里点“Show Dependencies”查出是哪一个传递依赖引入了冲突版本然后手动exclude掉。5.3 数据库认证问题MySQL 8的坑MySQL 8.0默认使用caching_sha2_password认证而有些老版本的MySQL驱动只支持mysql_native_password于是会出现登录成功但数据源初始化失败的情况。解决办法是升级驱动版本到mysql-connector-java 8.0.x以上或者在MySQL里把用户的认证插件改回旧版ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123456; FLUSH PRIVILEGES;注意新装项目不建议直接为了兼容去改数据库账号认证方式升级驱动才是正路。5.4 重复签到问题同一节课下产生多条记录如果你把唯一索引建在(tak_id, student_id)上这问题基本不会出现。但如果你的索引没建对或者Service层查询时没有把student_id过滤条件带全就可能出现两条“正常”签到的记录。排查方式先查数据库表确认重复记录的特征是同一任务还是不同任务然后回代码里看查询条件是否完整。还有一种隐蔽情况是前端把多个签到码内容拼接后一次性提交Service层又没有做长度校验导致语义相同的表单提交了两次。建议签到接口入参增加简单防重字段或者前端用一次性token提交后立刻失效。5.5 GPS定位不准阈值怎么调GPS定位不准是天然存在的不是代码bug。真实场景里学生在教学楼内签到拿到经纬度可能漂到教室外几百米。如果学生反馈“我在教室但显示不在范围”你可以按照以下步骤处理第一步先看前端是否成功取得坐标还是拿了缓存地址。第二步对比学生手机坐标和教师设置的签到坐标看偏差到底多大。第三步如果偏差在几十米以内适当调大半径到150米如果偏差几百米优先怀疑坐标系转换没做。另外提醒一点教师创建签到时如果手动填写某个地址解析出的经纬度要确认这个地址解析用的是哪个坐标系否则解析出来的坐标和学生手机坐标天然就不对。最好直接在教室现场取一个坐标作为签到点省掉之后一堆调整。5.6 常见问题速查表问题现象可能原因解决方法项目启动时端口被占用8080被其他进程占用换端口或杀掉占用进程登录后页面白屏前端资源路径错误或接口跨域检查静态资源配置/CORS配置签到按钮点了没反应Redis未启动或接口报错被吞先看Redis进程再看后端日志时间差8小时数据库连接串缺时区参数加serverTimezoneAsia/Shanghai中文存进数据库变成问号数据库字符集不是utf8重建数据库并指定utf8mb4二维码扫出来无法识别二维码内容拼错了URL检查二维码内容是否是完整前缀加签到码统计出勤率不准请假状态没和签到状态合并统计检查统计SQL中的请假记录过滤条件6. 配套资源LW调试文档讲解怎么用才有价值6.1 LW设计文档不是摆设是答辩主心骨很多同学拿到LW之后习惯直接改个名字这种做法风险很大。更合理的姿势是把它当作“骨架”用自己的话重新讲一遍需求分析和系统设计。因为答辩时老师很容易问“为什么用户表是这样设计的”“为什么选择这种签到方式”这些问题在LW里如果只是泛泛而谈你很难现场展开。参照我当时的做法把LW里的核心章节——需求分析、功能设计、数据库设计、核心流程图——分别用自己的话写成答辩草稿。绘图部分可以用ProcessOn或者Draw.io重新画一遍画的过程本身就是梳理逻辑的过程。流程图不需要多华丽但数据流向要清晰尤其是签到和请假这两条链路。6.2 调试文档配着源码看效率翻倍调试文档最大的作用是帮你快速定位问题但它不是逐行代码讲解手册。我建议的用法是先按调试文档把项目跑起来确认自己环境没问题跑起来之后挑一条主链路比如普通签到从头到尾跟一遍在关键Controller方法打断点看参数流转遇到问题先不要急着改代码先对照文档里的“常见问题”章节排除环境层面的坑文档读到最后再回到源码重点看Service层和Mapper层那是业务逻辑最密集的地方。补一个专属技巧调试时打开MyBatis-Plus的SQL日志我之前配置里的log-impl这样每个接口执行了哪些SQL语句一目了然。看到一个签到请求居然执行了六七条无关SQL大概率就是N1查询优化方向就能确定了。6.3 讲解视频/PPT怎么应对演示环节如果配套资源里有讲解视频或演示PPT别当成一个“要我照着念的稿子”。更实际的做法是抽象出一个“3分钟演示脚本”登录 → 教师创建一次二维码签到 → 学生扫码 → 教师看统计数据 → 导出Excel。这5个动作足以覆盖系统90%的核心功能也是大多答辩或验收环节里最常被要求走一遍的流程。演示之前最好准备两个浏览器窗口一个用教师账号一个用学生账号避免演示过程中反复切换登录。如果你在演示时网络不好提前把演示数据在本地库里准备好比如昨天已经签过到今天再补一次签到页面上一眼就能看到状态变化不用临时造数据。7. 这套系统的扩展方向与我的实操体会本来写到第6章就可以收尾了但很多拿到同类项目的人下一步面临的共同问题就是觉得“整个系统有点单薄”想在原有基础上加亮点。我根据自己的经验列几个性价比高且安全合规的扩展方向。第一个方向是做签到规则的多元化。比如支持“课时内随机签到”教师可以在上课过程中不定时发起一次临时签到用于识别签到后溜走的学生再比如支持“连堂课的多次签到”同一课程号码下允许发起多轮签到每次都独立计次。这些改动在现有数据模型上只需加一个轮次字段但功能体感会明显提升。第二个方向是把统计报表做得更符合学校/机构的表达习惯。目前我做的报表是通用的Excel导出但到了期末老师往往需要“按班级导出整学期的平时成绩汇总表”。这里可以在导出模块增加一个“导出模板选择”让教师按不同模板生成不同结构的Excel。因为业务逻辑不变只是组装数据的规则变了扩展起来很直接。第三个方向是增加消息通知。学生只靠刷新页面看到新签到任务体验比较被动。可以接入邮件、短信或公众号模板消息但其实更轻量的做法是在学生端首页挂一个倒计时组件教师发起签到后学生端只要打开页面就能看到任务和剩余时间。如果是在教室场景这个方法比任何消息推送都高效。我个人的体会是这套系统的难点从来不在“写一个签到按钮”而在“把签到和请假、课程、统计完整串起来”以及“如何让教师愿意在日常教学中真实使用”。很多设计在代码层面看已经完成了但只有拿到真实课堂里跑几轮才会暴露学生手机定位偏移、二维码被拍照传播、网络延迟导致重复提交这些问题。如果你正在开发同类系统我建议前期多花时间在异常分支和边界条件的处理上这才是考勤系统真正“能用”和“只能演示”的分水岭。最后再分享一个具体的小技巧在所有涉及时间的业务里接口返回给前端的时间格式统一加上格式化注解或者全局Jackson配置我习惯把LocalDateTime统一输出成yyyy-MM-dd HH:mm:ss。这个细节看着不起眼却能让前端少写很多格式化代码也避免后续排查问题时看一眼时间还要换算半天。整套系统从搭骨架到跑通数据库建表加上业务代码大概需要一周多照着本文第4章的步骤走一遍基本就能在自己的电脑上完整跑起来。如果在某个环节卡住记得先看日志日志里往往已经告诉你答案了。