做实验室考勤管理系统这个项目最初的起因是实验室排班表永远贴在门口学生忘签、代签、补签满天飞管理者月底统计累到崩溃。Spring Boot 微信小程序 Vue 前后端分离正是目前高校与科研团队里最常见的组合之一。这篇文章从产品定位、数据库设计、接口开发、小程序端实现到管理后台可视化一步步复盘整个系统的落地过程顺便把调试和文档里的坑也摊开讲。无论你是准备接同类课题、毕业设计还是实验室里想自己搞一套数字化考勤都值得参考一下。1. 实验室考勤的现状与产品定位为什么必须拆成小程序端和Web管理端1.1 纸质签到和群接龙到底差在哪我见过太多实验室的考勤方式还停留在门口挂一张A4纸进来就签个名。这种方式最大的问题不是签名容易潦草而是数据根本进不了统计。月底老师想查每人来了几次、在实验室待了多久只能翻纸翻到上火。后来有人改用微信群接龙但接龙消息被照片、聊天记录一冲照样乱。更重要的是这两种方式都防不了代签室友帮忙签个名老师基本发现不了。做这个系统之前我专门梳理过实验室考勤的几类需求第一类是门禁式签到人到了刷一下小程序就算打卡成功第二类是课时制考勤按课程或实验项目点名看谁缺席或迟到第三类是时段统计需要根据在馆时长折算工作量或绩效。这套系统要同时覆盖学生、老师、实验室管理员三种角色的诉求不能只做一个简单的打卡按钮。1.2 前后端分离的真正理由小程序端和管理端各司其职市面上有很多项目把小程序和管理后台塞在同一个服务里用模板引擎渲染页面结果小程序接口和后台页面互相干扰改一处崩一片。这个项目从架构上直接选择前后端分离理由其实不复杂学生端是微信小程序天然就是独立的客户端管理后台是Vue应用给老师和管理员在电脑上操作。两者只通过Spring Boot暴露的RESTful API通信互不干扰。这样做还有一个好处如果以后想换掉小程序端比如改成企业微信、App或者把Vue后台换成React只要后端接口设计得足够稳定前端重写一遍就行。数据库和业务逻辑不用动。反过来也一样如果考勤规则变了只调整后端接口小程序端和管理后台只要跟着契约变。这就是源码文档调试项目里最值钱的部分——接口文档写清楚了两端才能平行开发。1.3 技术选型的具体落地清单整个系统的技术栈可以列成一张很直白的表端技术方案说明后端Spring Boot 2.x MyBatis PlusBoot负责Web层MyBatis Plus负责数据库操作权限认证JWT Spring Security小程序端登录后获取Token管理后台登录后获取Token缓存Redis存储Token黑名单、防重复打卡的幂等标记小程序端微信原生框架用原生wxml/ js实现不引入uni-app降低依赖管理后台Vue 2 Element UI Axios后台页面组件化借用成熟UI框架快速搭建数据库MySQL 8.0建表、索引、关联查询稳定可靠接口调试Swagger Postman后端接口自动生成文档联调效率高选择这套组合最重要的原因是生态成熟。Spring Boot不用多说Java后端几乎绕不开它MyBatis Plus把单表CRUD简化到极致Vue管理端配Element UI界面虽然不是特别花哨但表格、表单、弹窗这些后台常用组件全都有几乎不用自己封装。记住一点实验室考勤系统最大的痛点不是技术难度而是需求逻辑复杂选方案要选自己最熟悉的别为了炫技引入一堆新框架。2. 数据库怎么建从用户、实验室到考勤记录的核心表设计2.1 五张基本表撑起所有考勤场景前后端分离项目后端的核心就是数据模型。我当时画了不下五版E-R图最后定下来的表结构其实非常克制。用户表、角色表、实验室表、课程表或排班表、考勤记录表加上请假表和补卡申请表七张表就够用了。用户表要区分学生、老师、管理员但不直接写死role字段而是用角色表和用户角色关联表这样以后想加一个实验室助理角色时不用改表结构。实验室表记录名称、位置、经纬度以及开放时间。课程表或排班表是考勤的档期排班表里有个字段叫check_deadline意思是本场考勤允许的迟到缓冲时间。考勤记录表是这张设计里最关键的字段包括用户ID、排班ID、签到时间、状态正常、迟到、早退、缺勤以及打卡来源小程序定位打卡/管理员补录。所有表都加create_time和update_time后面统计报表全靠这些时间字段。2.2 为什么微信用户和系统用户必须解耦很多项目一上来就把微信的openid塞进用户表里随着业务扩展就会出现问题用户的基本信息、微信标识、系统登录凭证全混在一起。我在这里把系统用户和微信身份分开。用户表只存学号/工号、姓名、手机号、部门或班级微信身份表单独存openid、unionid、session_key。第一次使用小程序时通过微信登录拿到openid再去用户身份表里查这个人是不是注册过的用户。这种设计的直接好处是一个用户可以绑定多个微信账号比如学生换微信号了不用重新注册管理员也可以主动给用户重置绑定。另外后端接口不要轻易把openid暴露给前端前端只需要在登录时传code给后端后端拿着code去微信接口换openid这样openid只存在后端和数据库避免被恶意利用。2.3 用MyBatis Plus生成器偷懒但别完全依赖写这些表的Mapper和实体类我是用MyBatis Plus代码生成器一键生成的。生成代码确实省时间但很多同学生成完就直接用发现字段命名、类型映射对不上就开始懵。我得提醒一下生成器只能按已有数据库表生成基础CRUD业务逻辑里那些多表联查、统计查询还是得自己手写SQL。比如查询某个学生本月出勤率需要关联用户表、排班表、考勤记录表三段子查询加起来才有结果不要指望生成器能替你写。在写完基础CRUD后建议立刻在Swagger里把每个接口的请求参数、返回结果测一遍别等前端写好了再联调。否则到时候查出来一个字段名大小写不一致两边都要折腾半天。3. 小程序端的考勤闭环登录、定位、打卡与补卡3.1 wx.login获取Token别忘了把Token存到Storage小程序端第一个要打通的就是登录流程。用户打开小程序后调用wx.login拿到临时code然后通过wx.request发给后端的/auth/login接口。后端拿到code后调用微信的code2Session接口换取openid和session_key再根据自己的用户表判断是否注册。如果注册过生成JWT返回给前端如果没注册返回一个标识引导用户去绑定学号。JWT返回后前端一定把它存到wx.setStorageSync(token, xxx)里。然后每次请求在wx.request的header里带Authorization: Bearer xxx。这里有个容易踩的坑小程序请求接口如果不在wx.login之后马上带Token后端很可能返回401。所以在app.js的onLaunch里最好先写一个promise包装的登录方法确保所有业务请求都等登录完成后再发。3.2 定位打卡别迷信微信的经纬度考勤系统最核心的打卡动作我用的是地理围栏方案。小程序端先通过wx.getLocation拿到当前经纬度然后传给后端后端再判断这个点是否在实验室设定的半径范围内比如以实验室坐标为圆心半径200米算在馆。这个方案看起来简单实际坑很多。微信的定位精度在不同手机上差异巨大同一部手机在室内有时候偏差能达到几百米。我的处理办法是后端不要只判断一个点而是接受一个经纬度数组用多个采样点做轨迹判断同时打开小程序的type: gcj02参数确保坐标系是国测局坐标数据库里保存的实验室坐标也必须是同一个坐标系。否则地图上明明是同一个位置后端算出来距离几百米学生永远打不了卡。另外我还在前端加了手动确认位置拍照的兜底逻辑当定位失败或判定不在围栏内时允许学生申请异常打卡由管理员或老师在后台审核。这套流程虽然多了一层审批但极大减少了误判投诉。3.3 打卡状态机的设计不能只有成功和失败考勤记录的状态绝不能只做一个布尔值。我把打卡状态设计成一个状态机未打卡、已打卡、请假、补卡待审、补卡成功、缺勤。学生点击打卡时后端不是简单insert一条记录而是先查排班表判断当前时间是否在允许打卡的时间段内。如果在开场前30分钟~开场后5分钟记为正常开场后5分钟~30分钟记为迟到超过30分钟直接拒绝打卡并提示本场已迟到超时。这种设计在写代码时很绕但非常必要。因为后面管理后台要自动生成缺勤名单、统计迟到率如果状态不明确这些报表全会是糊涂账。我在后端写了状态机枚举类用switch判断合法流转比如未打卡 - 迟到合法已打卡 - 缺勤不合法。前端也根据接口返回的status在页面上渲染不同文案这样学生打开小程序一眼就清楚自己是什么状态。3.4 补卡和请假必须走审批但审批流程要轻没有请假和补卡的考勤系统毫无人性。学生总有突然上课、生病、办急事的时候。我设计的是请假的入口在排班开始前24小时开放提交后自动流转给实验室管理员补卡入口只要打卡窗口关闭前都能提交但必须填理由并允许上传照片证明比如实验室群里的通知截图。管理员在Vue后台看到待审批列表点同意/拒绝后端状态机随之变化。审批逻辑最忌讳做成复杂的多级审批流实验室场景没必要。一个审批人就够了。我在后端用一个approval_records表记录谁审批的、什么时间、结果如何保证所有异常考勤都有痕迹。这些记录在月底做考勤申诉时特别有用否则管理者和学生各执一词完全没有依据。4. Vue管理后台排班管理、统计报表与异常审批页面4.1 Vue后台与技术栈选择Element UI足够不需要过多花哨管理后台用了Vue 2 Element UI。有人可能会说Vue 3都出多久了为什么还用Vue 2原因是Element UI最稳定网上资料最多而且这种后台系统又不需要复杂的组合式APIVue 2的选项式API对团队协作更友好。如果项目要继续维护Vue 2的组件库生态足以覆盖。我用vue/cli初始化项目配合vue-router做页面路由、axios做请求封装再用vuex存一下用户信息和菜单权限。核心页面其实就四个排班管理、考勤明细、异常审批、统计报表。排班管理页我用了Element UI的el-table展示所有排班信息支持按日期、实验室筛选考勤明细页是所有打卡记录的汇总可以按学生、日期、状态过滤异常审批页就是一个带状态的列表同意或拒绝按钮加上确认弹窗统计报表页最费心思因为要处理大量聚合数据。4.2 ECharts图表不是炫技是为了让管理者一眼看懂问题统计报表页如果只是把数据库里的数字列成表格老板根本不想看。我用ECharts画了三个关键的图每日出勤率折线图、时段环境人数热力图、学生考勤排行榜。热力图尤其受欢迎横轴是星期纵轴是小时颜色深浅代表实验室人数。管理者一眼就能看出周三下午实验室爆满或者周末几乎没人从而考虑是否需要调整开放时间。这些图的数据来源是后端专门写的统计接口比如/stats/attendance/trend?start...end...返回按天聚合的数组前端直接塞给ECharts。注意涉及统计的SQL要优化别用select *然后再内存里算。我一开始就是这么干的数据量小还好几千条就卡得不行。后来改成后端用GROUP BY DATE(create_time)和COUNT聚合响应时间从几秒降到几十毫秒。4.3 权限控制在前端只能算显示层真正校验必须靠后端Vue后台里的路由守卫比如管理员才能进入用户管理页这只是让界面看起来很安全。真正要防的是有人绕过前端直接调接口。所以我在后端给每个接口都加上了PreAuthorize注解JWT解析后校验角色。比如/user/list只有admin或teacher角色能访问/attendance/list只有teacher或admin能访问学生只能访问自己的记录。前端菜单根据登录后的用户角色动态渲染后端则每次请求都校验一遍两边各司其职。调试的时候我经常用Postman测试越权访问用一个学生Token去请求管理员的接口如果返回403说明权限控制生效一旦返回200就必须立刻修漏洞。考勤数据涉及学生隐私权限这关不能有任何侥幸。5. 前后端联调过程中的技术坑与排查链路5.1 跨域问题开发环境天天报别一股脑加CORS小程序端因为不在浏览器里其实不存在跨域问题。但Vue管理后台在浏览器里跑http://localhost:8080后端在http://localhost:8081必然跨域。很多同学第一反应在Controller上加CrossOrigin其实治标不治本。我在后端写了一个全局CORS配置类用addCorsMappings统一处理允许来源*允许GET/POST/PUT/DELETE并放行预检请求。排查时要记住如果请求头里带了AuthorizationallowedHeaders必须显式包含它。否则浏览器预检请求直接失败控制台会报Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response。这个问题在Swagger里测不出来因为Swagger是后端自己发请求压根不经历跨域。5.2 Token过期和并发登录这两个问题不处理好用户会骂人JWT默认是无状态的过期时间一到前端如果没主动处理用户正在操作的时候突然被踢下线体验极差。我的办法是前端用axios拦截器统一捕获401响应立即跳转到登录页并提示登录状态已过期请重新登录。但是如果用户正在小程序里打卡刚完成一半直接被踢出去岂不是还要重新登录我在后端把Token的有效期设置得比较长配合刷新机制每次请求如果Token剩余有效期低于一半就下发一个新Token前端更新Storage。同时用Redis存了一个Token黑名单用户主动退出时把当前Token加入黑名单确保旧Token彻底失效。并发登录的问题是用户可能用两个手机同时登录。考勤场景比较特殊我不希望同一个账号同时在线还能同时打卡于是后端把每个用户的最新sessionToken存进Redis旧的直接作废。这在微信小程序里其实很少遇到但后台管理账号如果被人共用这个问题就会显出来。实测下来这一套机制虽然增加了代码量但稳定性和安全性都提升了一个档次。5.3 定位误差引发的误判最典型的排查链路有次开发完测试反馈人明明在实验室里打卡显示不在范围内。我排错过程是这样的先看数据库里实验室坐标是否录入准确果然发现实验室地址是随便从地图上抠的坐标和实际门口差了100米。重新用小程序获取实验室内部的经纬度并更新数据库问题消失了大半。接着又发现有些手机定位结果飘到隔壁楼我在前端代码里增加了定位失败时的提示并引导用户打开GPS开关、检查位置权限。最后把地理围栏半径从100米放宽到200米同时加了连续定位三次取交集的策略误报率降到了可接受范围。这个过程中最有用的工具是后端接口日志。我把每个打卡请求里的用户经纬度、实验室经纬度、计算距离全部打印到日志里通过日志就能看到某台手机报上来的坐标到底离实验室多远。有了完整日志就不用再反复问测试你到底站哪了直接看数据说话。5.4 数据库时间与服务器时间不一致的隐患考勤系统一旦依赖当前时间判断迟到就绝对不能出现时间漂移。我有一次发现本地的MySQL时间和服务器上Java进程的new Date()差了8个小时导致所有打卡记录都错位。根因是数据库连接串里的serverTimezone参数没有设为Asia/Shanghai机器时区又不一样。排查下来之后我在JDBC连接串里手动加了serverTimezoneAsia/Shanghai并让后端所有业务统一使用服务端时间的LocalDateTime而不是前端传过来的本地时间。这个坑特别隐蔽因为开发机上MySQL和Java在同一台电脑几乎不会察觉一上云服务器就爆雷。6. 从源码到交付文档、调试与部署的完整经验6.1 源码结构怎么组织别人一眼能看懂一个源码文档调试的项目源码结构如果乱七八糟后面维护就是灾难。我的后端包名按模块分controller、service、mapper、entity、dto、config、common。业务模块采用auth登录认证、user用户管理、lab实验室、schedule排班、attendance考勤、approval审批、stats统计。小程序端则按页面分目录pages/login、pages/checkIn、pages/leave、pages/mine。Vue后台按路由视图分目录每个业务模块下自带api.js和index.vue。我特别强调一个习惯每个模块的Controller只负责参数校验和返回值组装业务逻辑全部放在Service层。这样写单元测试的时候只用测Service不需要起Web容器。别忘了在application.yml里配置好不同环境的Profile比如dev、test、prod至少数据库连接、Redis地址、日志级别要分开。否则把开发环境的密码带到生产环境迟早出事。6.2 文档不只是给看的人也是给自己复查的线索很多人写文档前言不搭后语接口文档几行字就过。这个项目因为是交付型项目我按需求说明、数据库设计、接口文档、部署手册、测试报告五个部分写。其中接口文档用Swagger自动生成再在代码里补充注释比如每个参数的含义、取值范围、返回码。部署手册一定要写清楚Java版本、Node版本、MySQL和Redis的启动方式、Nginx配置以及微信小程序后台的AppID和密钥配置位置。我踩过的坑是第一次写部署文档时漏了微信公众平台需要配置request合法域名这一步。结果前端拿不到接口数据学生以为系统崩溃了。后来我把这个配置单独拉出来高亮并附上详细的路径小程序后台 - 开发 - 开发设置 - 服务器域名。文档的价值不是写完放那就完而是要让一个没参与过开发的人照着文档半小时内能把系统跑起来。6.3 调试经验没有真机测试考勤系统就是一张废纸小程序端必须用真机调试模拟器里定位是假的相机是假的权限弹窗也是假的。我一般在微信开发者工具里做逻辑调试然后用预览二维码在安卓和苹果手机上各测一遍。特别要测的是手机熄屏后小程序能否恢复会话、断网状态下的提示、后台Manager撤回到前台的定位重新获取。代码写完不代调试调试并不是简单跑一遍流程而是要故意输入异常情况重复点击打卡按钮、网络超时后重试、跨天打卡等等。后端调试我习惯用全局异常处理器把所有未捕获异常统一包装成{code:500, msg:...}返回并在日志里打印堆栈。这样前端不会直接看到控制台的英文报错用户只会收到友好的提示。每次发布前我会在Postman里过一遍核心接口的冒烟测试确认登录、排班、打卡、统计四个主链路都通。6.4 部署到服务器Nginx反向代理和前后端各自为政部署时我把Spring Boot打成jar包用systemd托管Vue打包成dist静态文件交给Nginx托管小程序端不用部署直接发布到微信平台。后端在application-prod.yml里关闭Swagger数据库换成云数据库Redis也用云Redis。Nginx里配置两个server块一个server监听80端口转发/api/*到后端127.0.0.1:8081另一个server监听443端口托管Vue的静态文件并配置SSL证书。注意Vue路由必须开启history模式否则刷新页面就404需要在Nginx里加上try_files $uri $uri/ /index.html;。部署当中还会遇到一个小问题服务器时区和数据库时区。我统一在启动脚本里加-Duser.timezoneGMT08并在MySQL初始化时设置default-time-zone08:00。时间问题解决之后整个系统的考勤记录才真正可信。7. 最后再聊几句实战体会这套项目从零开始到稳定运行前后大概花了两周多的业余时间。最深刻的体会是技术上没有什么高深莫测的东西真正的复杂度都藏在业务边界里。比如什么算迟到补卡审批到底需要哪几步管理员能不能替学生打卡这些问题一旦没想清楚程序写得再漂亮也白搭。所以我的顺序永远是先理清楚考勤规则再画表结构最后才写接口和页面。如果你也想动手做类似项目我建议不要一上来就想着一股脑全做出来。先跑通一个最简闭环后端登录接口 小程序打卡 后台看记录。等这个闭环稳定了再逐步加请假、补卡、统计图表、权限控制。做项目的过程中一定要写日志、写文档不仅是为了交付也是为了让你自己隔两周再回头改bug时不至于懵。我最后还留了个扩展点这套考勤系统可以无缝对接门禁机、校园卡只要在打卡入口再加一个“刷卡或NFC”的通道就行。到时候学生连手机都不用掏物理卡刷一下就能完成考勤那又是另一个有意思的方向了。 
长河君 · 2026/10/13 17:27:47 · 阅读 1.2k Spring Boot+微信小程序+Vue：实验室考勤管理系统全栈实战
做实验室考勤管理系统这个项目最初的起因是实验室排班表永远贴在门口学生忘签、代签、补签满天飞管理者月底统计累到崩溃。Spring Boot 微信小程序 Vue 前后端分离正是目前高校与科研团队里最常见的组合之一。这篇文章从产品定位、数据库设计、接口开发、小程序端实现到管理后台可视化一步步复盘整个系统的落地过程顺便把调试和文档里的坑也摊开讲。无论你是准备接同类课题、毕业设计还是实验室里想自己搞一套数字化考勤都值得参考一下。1. 实验室考勤的现状与产品定位为什么必须拆成小程序端和Web管理端1.1 纸质签到和群接龙到底差在哪我见过太多实验室的考勤方式还停留在门口挂一张A4纸进来就签个名。这种方式最大的问题不是签名容易潦草而是数据根本进不了统计。月底老师想查每人来了几次、在实验室待了多久只能翻纸翻到上火。后来有人改用微信群接龙但接龙消息被照片、聊天记录一冲照样乱。更重要的是这两种方式都防不了代签室友帮忙签个名老师基本发现不了。做这个系统之前我专门梳理过实验室考勤的几类需求第一类是门禁式签到人到了刷一下小程序就算打卡成功第二类是课时制考勤按课程或实验项目点名看谁缺席或迟到第三类是时段统计需要根据在馆时长折算工作量或绩效。这套系统要同时覆盖学生、老师、实验室管理员三种角色的诉求不能只做一个简单的打卡按钮。1.2 前后端分离的真正理由小程序端和管理端各司其职市面上有很多项目把小程序和管理后台塞在同一个服务里用模板引擎渲染页面结果小程序接口和后台页面互相干扰改一处崩一片。这个项目从架构上直接选择前后端分离理由其实不复杂学生端是微信小程序天然就是独立的客户端管理后台是Vue应用给老师和管理员在电脑上操作。两者只通过Spring Boot暴露的RESTful API通信互不干扰。这样做还有一个好处如果以后想换掉小程序端比如改成企业微信、App或者把Vue后台换成React只要后端接口设计得足够稳定前端重写一遍就行。数据库和业务逻辑不用动。反过来也一样如果考勤规则变了只调整后端接口小程序端和管理后台只要跟着契约变。这就是源码文档调试项目里最值钱的部分——接口文档写清楚了两端才能平行开发。1.3 技术选型的具体落地清单整个系统的技术栈可以列成一张很直白的表端技术方案说明后端Spring Boot 2.x MyBatis PlusBoot负责Web层MyBatis Plus负责数据库操作权限认证JWT Spring Security小程序端登录后获取Token管理后台登录后获取Token缓存Redis存储Token黑名单、防重复打卡的幂等标记小程序端微信原生框架用原生wxml/ js实现不引入uni-app降低依赖管理后台Vue 2 Element UI Axios后台页面组件化借用成熟UI框架快速搭建数据库MySQL 8.0建表、索引、关联查询稳定可靠接口调试Swagger Postman后端接口自动生成文档联调效率高选择这套组合最重要的原因是生态成熟。Spring Boot不用多说Java后端几乎绕不开它MyBatis Plus把单表CRUD简化到极致Vue管理端配Element UI界面虽然不是特别花哨但表格、表单、弹窗这些后台常用组件全都有几乎不用自己封装。记住一点实验室考勤系统最大的痛点不是技术难度而是需求逻辑复杂选方案要选自己最熟悉的别为了炫技引入一堆新框架。2. 数据库怎么建从用户、实验室到考勤记录的核心表设计2.1 五张基本表撑起所有考勤场景前后端分离项目后端的核心就是数据模型。我当时画了不下五版E-R图最后定下来的表结构其实非常克制。用户表、角色表、实验室表、课程表或排班表、考勤记录表加上请假表和补卡申请表七张表就够用了。用户表要区分学生、老师、管理员但不直接写死role字段而是用角色表和用户角色关联表这样以后想加一个实验室助理角色时不用改表结构。实验室表记录名称、位置、经纬度以及开放时间。课程表或排班表是考勤的档期排班表里有个字段叫check_deadline意思是本场考勤允许的迟到缓冲时间。考勤记录表是这张设计里最关键的字段包括用户ID、排班ID、签到时间、状态正常、迟到、早退、缺勤以及打卡来源小程序定位打卡/管理员补录。所有表都加create_time和update_time后面统计报表全靠这些时间字段。2.2 为什么微信用户和系统用户必须解耦很多项目一上来就把微信的openid塞进用户表里随着业务扩展就会出现问题用户的基本信息、微信标识、系统登录凭证全混在一起。我在这里把系统用户和微信身份分开。用户表只存学号/工号、姓名、手机号、部门或班级微信身份表单独存openid、unionid、session_key。第一次使用小程序时通过微信登录拿到openid再去用户身份表里查这个人是不是注册过的用户。这种设计的直接好处是一个用户可以绑定多个微信账号比如学生换微信号了不用重新注册管理员也可以主动给用户重置绑定。另外后端接口不要轻易把openid暴露给前端前端只需要在登录时传code给后端后端拿着code去微信接口换openid这样openid只存在后端和数据库避免被恶意利用。2.3 用MyBatis Plus生成器偷懒但别完全依赖写这些表的Mapper和实体类我是用MyBatis Plus代码生成器一键生成的。生成代码确实省时间但很多同学生成完就直接用发现字段命名、类型映射对不上就开始懵。我得提醒一下生成器只能按已有数据库表生成基础CRUD业务逻辑里那些多表联查、统计查询还是得自己手写SQL。比如查询某个学生本月出勤率需要关联用户表、排班表、考勤记录表三段子查询加起来才有结果不要指望生成器能替你写。在写完基础CRUD后建议立刻在Swagger里把每个接口的请求参数、返回结果测一遍别等前端写好了再联调。否则到时候查出来一个字段名大小写不一致两边都要折腾半天。3. 小程序端的考勤闭环登录、定位、打卡与补卡3.1 wx.login获取Token别忘了把Token存到Storage小程序端第一个要打通的就是登录流程。用户打开小程序后调用wx.login拿到临时code然后通过wx.request发给后端的/auth/login接口。后端拿到code后调用微信的code2Session接口换取openid和session_key再根据自己的用户表判断是否注册。如果注册过生成JWT返回给前端如果没注册返回一个标识引导用户去绑定学号。JWT返回后前端一定把它存到wx.setStorageSync(token, xxx)里。然后每次请求在wx.request的header里带Authorization: Bearer xxx。这里有个容易踩的坑小程序请求接口如果不在wx.login之后马上带Token后端很可能返回401。所以在app.js的onLaunch里最好先写一个promise包装的登录方法确保所有业务请求都等登录完成后再发。3.2 定位打卡别迷信微信的经纬度考勤系统最核心的打卡动作我用的是地理围栏方案。小程序端先通过wx.getLocation拿到当前经纬度然后传给后端后端再判断这个点是否在实验室设定的半径范围内比如以实验室坐标为圆心半径200米算在馆。这个方案看起来简单实际坑很多。微信的定位精度在不同手机上差异巨大同一部手机在室内有时候偏差能达到几百米。我的处理办法是后端不要只判断一个点而是接受一个经纬度数组用多个采样点做轨迹判断同时打开小程序的type: gcj02参数确保坐标系是国测局坐标数据库里保存的实验室坐标也必须是同一个坐标系。否则地图上明明是同一个位置后端算出来距离几百米学生永远打不了卡。另外我还在前端加了手动确认位置拍照的兜底逻辑当定位失败或判定不在围栏内时允许学生申请异常打卡由管理员或老师在后台审核。这套流程虽然多了一层审批但极大减少了误判投诉。3.3 打卡状态机的设计不能只有成功和失败考勤记录的状态绝不能只做一个布尔值。我把打卡状态设计成一个状态机未打卡、已打卡、请假、补卡待审、补卡成功、缺勤。学生点击打卡时后端不是简单insert一条记录而是先查排班表判断当前时间是否在允许打卡的时间段内。如果在开场前30分钟~开场后5分钟记为正常开场后5分钟~30分钟记为迟到超过30分钟直接拒绝打卡并提示本场已迟到超时。这种设计在写代码时很绕但非常必要。因为后面管理后台要自动生成缺勤名单、统计迟到率如果状态不明确这些报表全会是糊涂账。我在后端写了状态机枚举类用switch判断合法流转比如未打卡 - 迟到合法已打卡 - 缺勤不合法。前端也根据接口返回的status在页面上渲染不同文案这样学生打开小程序一眼就清楚自己是什么状态。3.4 补卡和请假必须走审批但审批流程要轻没有请假和补卡的考勤系统毫无人性。学生总有突然上课、生病、办急事的时候。我设计的是请假的入口在排班开始前24小时开放提交后自动流转给实验室管理员补卡入口只要打卡窗口关闭前都能提交但必须填理由并允许上传照片证明比如实验室群里的通知截图。管理员在Vue后台看到待审批列表点同意/拒绝后端状态机随之变化。审批逻辑最忌讳做成复杂的多级审批流实验室场景没必要。一个审批人就够了。我在后端用一个approval_records表记录谁审批的、什么时间、结果如何保证所有异常考勤都有痕迹。这些记录在月底做考勤申诉时特别有用否则管理者和学生各执一词完全没有依据。4. Vue管理后台排班管理、统计报表与异常审批页面4.1 Vue后台与技术栈选择Element UI足够不需要过多花哨管理后台用了Vue 2 Element UI。有人可能会说Vue 3都出多久了为什么还用Vue 2原因是Element UI最稳定网上资料最多而且这种后台系统又不需要复杂的组合式APIVue 2的选项式API对团队协作更友好。如果项目要继续维护Vue 2的组件库生态足以覆盖。我用vue/cli初始化项目配合vue-router做页面路由、axios做请求封装再用vuex存一下用户信息和菜单权限。核心页面其实就四个排班管理、考勤明细、异常审批、统计报表。排班管理页我用了Element UI的el-table展示所有排班信息支持按日期、实验室筛选考勤明细页是所有打卡记录的汇总可以按学生、日期、状态过滤异常审批页就是一个带状态的列表同意或拒绝按钮加上确认弹窗统计报表页最费心思因为要处理大量聚合数据。4.2 ECharts图表不是炫技是为了让管理者一眼看懂问题统计报表页如果只是把数据库里的数字列成表格老板根本不想看。我用ECharts画了三个关键的图每日出勤率折线图、时段环境人数热力图、学生考勤排行榜。热力图尤其受欢迎横轴是星期纵轴是小时颜色深浅代表实验室人数。管理者一眼就能看出周三下午实验室爆满或者周末几乎没人从而考虑是否需要调整开放时间。这些图的数据来源是后端专门写的统计接口比如/stats/attendance/trend?start...end...返回按天聚合的数组前端直接塞给ECharts。注意涉及统计的SQL要优化别用select *然后再内存里算。我一开始就是这么干的数据量小还好几千条就卡得不行。后来改成后端用GROUP BY DATE(create_time)和COUNT聚合响应时间从几秒降到几十毫秒。4.3 权限控制在前端只能算显示层真正校验必须靠后端Vue后台里的路由守卫比如管理员才能进入用户管理页这只是让界面看起来很安全。真正要防的是有人绕过前端直接调接口。所以我在后端给每个接口都加上了PreAuthorize注解JWT解析后校验角色。比如/user/list只有admin或teacher角色能访问/attendance/list只有teacher或admin能访问学生只能访问自己的记录。前端菜单根据登录后的用户角色动态渲染后端则每次请求都校验一遍两边各司其职。调试的时候我经常用Postman测试越权访问用一个学生Token去请求管理员的接口如果返回403说明权限控制生效一旦返回200就必须立刻修漏洞。考勤数据涉及学生隐私权限这关不能有任何侥幸。5. 前后端联调过程中的技术坑与排查链路5.1 跨域问题开发环境天天报别一股脑加CORS小程序端因为不在浏览器里其实不存在跨域问题。但Vue管理后台在浏览器里跑http://localhost:8080后端在http://localhost:8081必然跨域。很多同学第一反应在Controller上加CrossOrigin其实治标不治本。我在后端写了一个全局CORS配置类用addCorsMappings统一处理允许来源*允许GET/POST/PUT/DELETE并放行预检请求。排查时要记住如果请求头里带了AuthorizationallowedHeaders必须显式包含它。否则浏览器预检请求直接失败控制台会报Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response。这个问题在Swagger里测不出来因为Swagger是后端自己发请求压根不经历跨域。5.2 Token过期和并发登录这两个问题不处理好用户会骂人JWT默认是无状态的过期时间一到前端如果没主动处理用户正在操作的时候突然被踢下线体验极差。我的办法是前端用axios拦截器统一捕获401响应立即跳转到登录页并提示登录状态已过期请重新登录。但是如果用户正在小程序里打卡刚完成一半直接被踢出去岂不是还要重新登录我在后端把Token的有效期设置得比较长配合刷新机制每次请求如果Token剩余有效期低于一半就下发一个新Token前端更新Storage。同时用Redis存了一个Token黑名单用户主动退出时把当前Token加入黑名单确保旧Token彻底失效。并发登录的问题是用户可能用两个手机同时登录。考勤场景比较特殊我不希望同一个账号同时在线还能同时打卡于是后端把每个用户的最新sessionToken存进Redis旧的直接作废。这在微信小程序里其实很少遇到但后台管理账号如果被人共用这个问题就会显出来。实测下来这一套机制虽然增加了代码量但稳定性和安全性都提升了一个档次。5.3 定位误差引发的误判最典型的排查链路有次开发完测试反馈人明明在实验室里打卡显示不在范围内。我排错过程是这样的先看数据库里实验室坐标是否录入准确果然发现实验室地址是随便从地图上抠的坐标和实际门口差了100米。重新用小程序获取实验室内部的经纬度并更新数据库问题消失了大半。接着又发现有些手机定位结果飘到隔壁楼我在前端代码里增加了定位失败时的提示并引导用户打开GPS开关、检查位置权限。最后把地理围栏半径从100米放宽到200米同时加了连续定位三次取交集的策略误报率降到了可接受范围。这个过程中最有用的工具是后端接口日志。我把每个打卡请求里的用户经纬度、实验室经纬度、计算距离全部打印到日志里通过日志就能看到某台手机报上来的坐标到底离实验室多远。有了完整日志就不用再反复问测试你到底站哪了直接看数据说话。5.4 数据库时间与服务器时间不一致的隐患考勤系统一旦依赖当前时间判断迟到就绝对不能出现时间漂移。我有一次发现本地的MySQL时间和服务器上Java进程的new Date()差了8个小时导致所有打卡记录都错位。根因是数据库连接串里的serverTimezone参数没有设为Asia/Shanghai机器时区又不一样。排查下来之后我在JDBC连接串里手动加了serverTimezoneAsia/Shanghai并让后端所有业务统一使用服务端时间的LocalDateTime而不是前端传过来的本地时间。这个坑特别隐蔽因为开发机上MySQL和Java在同一台电脑几乎不会察觉一上云服务器就爆雷。6. 从源码到交付文档、调试与部署的完整经验6.1 源码结构怎么组织别人一眼能看懂一个源码文档调试的项目源码结构如果乱七八糟后面维护就是灾难。我的后端包名按模块分controller、service、mapper、entity、dto、config、common。业务模块采用auth登录认证、user用户管理、lab实验室、schedule排班、attendance考勤、approval审批、stats统计。小程序端则按页面分目录pages/login、pages/checkIn、pages/leave、pages/mine。Vue后台按路由视图分目录每个业务模块下自带api.js和index.vue。我特别强调一个习惯每个模块的Controller只负责参数校验和返回值组装业务逻辑全部放在Service层。这样写单元测试的时候只用测Service不需要起Web容器。别忘了在application.yml里配置好不同环境的Profile比如dev、test、prod至少数据库连接、Redis地址、日志级别要分开。否则把开发环境的密码带到生产环境迟早出事。6.2 文档不只是给看的人也是给自己复查的线索很多人写文档前言不搭后语接口文档几行字就过。这个项目因为是交付型项目我按需求说明、数据库设计、接口文档、部署手册、测试报告五个部分写。其中接口文档用Swagger自动生成再在代码里补充注释比如每个参数的含义、取值范围、返回码。部署手册一定要写清楚Java版本、Node版本、MySQL和Redis的启动方式、Nginx配置以及微信小程序后台的AppID和密钥配置位置。我踩过的坑是第一次写部署文档时漏了微信公众平台需要配置request合法域名这一步。结果前端拿不到接口数据学生以为系统崩溃了。后来我把这个配置单独拉出来高亮并附上详细的路径小程序后台 - 开发 - 开发设置 - 服务器域名。文档的价值不是写完放那就完而是要让一个没参与过开发的人照着文档半小时内能把系统跑起来。6.3 调试经验没有真机测试考勤系统就是一张废纸小程序端必须用真机调试模拟器里定位是假的相机是假的权限弹窗也是假的。我一般在微信开发者工具里做逻辑调试然后用预览二维码在安卓和苹果手机上各测一遍。特别要测的是手机熄屏后小程序能否恢复会话、断网状态下的提示、后台Manager撤回到前台的定位重新获取。代码写完不代调试调试并不是简单跑一遍流程而是要故意输入异常情况重复点击打卡按钮、网络超时后重试、跨天打卡等等。后端调试我习惯用全局异常处理器把所有未捕获异常统一包装成{code:500, msg:...}返回并在日志里打印堆栈。这样前端不会直接看到控制台的英文报错用户只会收到友好的提示。每次发布前我会在Postman里过一遍核心接口的冒烟测试确认登录、排班、打卡、统计四个主链路都通。6.4 部署到服务器Nginx反向代理和前后端各自为政部署时我把Spring Boot打成jar包用systemd托管Vue打包成dist静态文件交给Nginx托管小程序端不用部署直接发布到微信平台。后端在application-prod.yml里关闭Swagger数据库换成云数据库Redis也用云Redis。Nginx里配置两个server块一个server监听80端口转发/api/*到后端127.0.0.1:8081另一个server监听443端口托管Vue的静态文件并配置SSL证书。注意Vue路由必须开启history模式否则刷新页面就404需要在Nginx里加上try_files $uri $uri/ /index.html;。部署当中还会遇到一个小问题服务器时区和数据库时区。我统一在启动脚本里加-Duser.timezoneGMT08并在MySQL初始化时设置default-time-zone08:00。时间问题解决之后整个系统的考勤记录才真正可信。7. 最后再聊几句实战体会这套项目从零开始到稳定运行前后大概花了两周多的业余时间。最深刻的体会是技术上没有什么高深莫测的东西真正的复杂度都藏在业务边界里。比如什么算迟到补卡审批到底需要哪几步管理员能不能替学生打卡这些问题一旦没想清楚程序写得再漂亮也白搭。所以我的顺序永远是先理清楚考勤规则再画表结构最后才写接口和页面。如果你也想动手做类似项目我建议不要一上来就想着一股脑全做出来。先跑通一个最简闭环后端登录接口 小程序打卡 后台看记录。等这个闭环稳定了再逐步加请假、补卡、统计图表、权限控制。做项目的过程中一定要写日志、写文档不仅是为了交付也是为了让你自己隔两周再回头改bug时不至于懵。我最后还留了个扩展点这套考勤系统可以无缝对接门禁机、校园卡只要在打卡入口再加一个“刷卡或NFC”的通道就行。到时候学生连手机都不用掏物理卡刷一下就能完成考勤那又是另一个有意思的方向了。