做毕业设计选到这个题目的同学我太懂你了。“基于微信小程序的课堂考勤签到系统”乍一看就是个老掉牙的CRUD项目网上源码一抓一大把配套LW文档论文文档也有现成的。但我想说句实在话正因为这个题目太普遍老师一眼就能看出你是真做了还是纯凑合。我当年做同类项目时踩过的坑、答辩被追问的细节今天一次性给你讲清楚。这篇文章不打算给你罗列“完整源码”而是告诉你怎么把这个题目做成一个经得起追问的毕业设计从为什么选型、数据表怎么设计、签到流程怎么防代签到LW文档怎么写才能让老师觉得你有思考再到开发中那些真机测试才暴露的坑。无论你是准备自己撸代码还是手里已经有一份源码文档想改造成自己的东西这篇都能帮你少走很多弯路。1. 为什么毕业设计选这个题目读懂需求再动手比找源码重要得多1.1 这个题目到底在考察什么先拆一下题面。“基于微信小程序的课堂考勤签到系统”三个关键词微信小程序、课堂考勤、签到系统。翻译成毕设语言就是一套完整的前后端分离应用学生用微信小程序完成签到教师能发起签到、查看统计后台有数据管理能力。很多同学看到“源码文档”就兴奋觉得下载下来改个名字就能交差。但答辩老师不傻他随口问一句“你的签到时间校验逻辑写在哪一层”你就得能接住。这个题目的隐藏考点其实是这三个移动端适配小程序不是网页它有冷启动、授权流程、生命周期、审核机制这些都要体现在你的项目里。地理位置打卡课堂签到最常见的算法场景是基于经纬度的距离判断这是论文里能写、答辩能讲的“硬核点”。角色权限体系学生、教师、管理员三种角色怎么区分接口怎么防越权这是区分“会写代码”和“懂设计”的分水岭。另外还有一层隐性需求课堂签到要解决的是代签、晚到、统计繁琐这三个痛点。如果你的设计里没有针对其中任何一个给出可落地的方案那整个项目就是套壳。1.2 选型之前先把坑想明白我看到不少同学一上来就问“用原生小程序还是uniapp”“后端用Java还是Node”这种问题其实应该反过来问你的毕设周期有多长答辩老师偏好什么样的技术栈你本身哪块最熟。以我自己带过和做过的经验来看最稳妥的组合是前端微信小程序原生开发后端Spring BootJava数据库MySQL为什么不是uniapp不是它不好是原生小程序在毕设场景下出错更少、资料更全、答辩更好讲。uniapp多了一层编译转换真机调试时偶尔出一些莫名其妙的问题你还要额外解释“为什么跨端框架在微信上表现不稳定”等于给自己加戏。Spring Boot就更不用说了Java后端在计算机类毕设里占有率极高遇到问题搜一下全是对应方案而且老师大概率看得懂Java代码。另一个近年很流行的方案是微信云开发不用自己买服务器、不用配域名云函数直接读写云数据库。说实话做原型非常快但我劝你慎选。原因很现实毕设论文里“系统架构”那一章会让你很难写因为没有传统意义上的后端服务你没法画清晰的请求链路图。而且答辩老师如果有Java背景会一直追问“云函数的安全性怎么保证”反而容易翻车。用传统前后端分离论文素材最完整。2. 整体架构与核心设计一个人怎么把系统拆得明明白白2.1 功能模块拆分与页面清单拿到题目第一步不是写代码是画功能清单。别小看这一步你的LW文档第三章“需求分析”全靠它撑场面。我当时把系统拆成了三个端学生端小程序端微信登录通过wx.login获取code后端换openid建立账号体系课程签到查看当前待签到课程一键定位打卡签到记录按日期查看历史出勤列表支持分页加载请假申请提交请假原因等待教师审批教师端小程序端发起签到选择课程、设置签到时间窗口、自动携带课程地点坐标签到详情实时查看已签到/未签到名单支持迟到标记审批请假同意或驳回学生的请假申请出勤统计按课程/按时间维度查看出勤率管理端Web后台用户管理导入学生名单、教师名单重置密码课程管理绑定课程与教师、设置上课时间和地点数据看板全校出勤率趋势、各课程迟到率排行页面规划上小程序端我建议控制在8~10个页面以内太多了写不完太少了显得单薄。我的清单是登录页、首页课程列表、签到详情页、记录列表页、请假表单页、教师工作台、发起签到页、课程统计页、个人中心页。这里的技巧是页面数量不要追求多要把每个页面的交互讲清楚。比如首页课程列表不是简单的列表渲染需要区分“待签到”“已签到”“已迟到”三种状态卡片这是能写进论文的功能亮点。2.2 数据表设计这几张表决定了答辩时你能说多细数据库设计是LW文档“概要设计”的核心素材也是老师必看的内容。我总结了一套适合课堂考勤的最小但完整的表结构用户表sys_userid、openid、学号/工号、姓名、角色、头像、创建时间。openid必须加唯一索引这是小程序登录体系的锚点。课程表courseid、课程名、教师id、上课周次、开始时间、结束时间、教室ID。这里要和签到场景联动所以课程地点坐标latitude、longitude建议直接存在课程表里发起签到时直接从课程带上坐标。签到任务表sign_taskid、课程id、发起教师id、签到码、开始时间、结束时间、签到地点经纬度、允许签到的半径米、状态。这张表是最核心的因为“签到”在这里是一个可以复用的动作。签到记录表sign_recordid、任务id、学生id、签到时间、提交的经纬度、与签到地点的距离、签到状态正常/迟到、是否代签标记。这张表的唯一索引建议设置为task_id、student_id直接防止重复签到。请假表leave_requestid、学生id、课程id、请假原因、状态、审批时间。为什么要在这里反复强调索引因为答辩时如果老师问你“怎么防止一个学生签到两次”除了前端按钮置灰你还要说出“后端唯一索引兜底”这层设计。这才是真正体现你思考深度的地方。单个学生和课程是多对多的关系所以还要考虑学生选课表student_course这个表虽然简单但能撑起“用户-课程”关联建议也加上不然签到记录和课程对不上。2.3 定位签到的原理从经纬度到“距离小于50米”课堂考勤签到最核心的算法不是人脸识别也不是扫二维码这两个都能被绕过而是地理围栏签到。原理用大白话说教师在某个教室发起签到系统保存这个教室的经纬度坐标和签到范围半径比如50米。学生签到时小程序获取学生当前经纬度计算这两个经纬度的球面距离如果小于50米判定为“在教室”允许签到。球面距离不能直接用平面勾股定理算因为地球是个椭球体。行业常用的是Haversine公式a sin²(Δlat/2) cos(lat1) * cos(lat2) * sin²(Δlng/2) c 2 * atan2(√a, √(1−a)) distance R * c // R取6371km公式看着唬人其实就是把两点经纬度换算成球面上的弧长。后端Java里可以直接用Math库实现不用额外引依赖。如果你用的MySQL 5.7以上版本也可以用自带的st_distance_sphere函数但为了论文里能展示算法思路建议自己在Service层里写一遍别全交给数据库黑盒。除了距离判断还得加上时间判断。签到任务表里有开始时间和结束时间前端提交签到请求时后端要判断当前时间早于开始时间不在签到窗口当前时间在开始时间到开始10分钟内正常签到当前时间在开始10分钟之后到结束时间标记为迟到当前时间晚于结束时间拒绝签到这里有个很容易被忽略的细节前后端时间必须统一用时间戳或者标准时区我当时就吃过亏数据库存的是本地时间服务器部署在另一个时区导致签到窗口错乱了两个小时排查了一整天才发现。3. 核心流程实现登录、发签到、防代签的完整链路3.1 登录与Session管理wx.login的code到底怎么换openid微信小程序没有传统的“账号密码登录”它的标准流程是小程序端调用wx.login()拿到一个临时凭证code。小程序把code通过wx.request发给自己的后端接口比如POST /api/auth/login。后端拿着这个code去请求微信官方的code2Session接口拿到openid和session_key。后端用openid查用户表如果查不到说明是第一次使用自动注册查得到直接登录。后端自己生成一个token可以是UUID或者JWT返回给小程序。小程序把token存在wx.setStorageSync里后续所有请求头部带上这个token。这个流程里新手最容易犯的错是把code当成登录凭证反复用实际上code是一次性的五分钟内有效用一次就作废。正常的设计是后端用code换完openid之后就生成自己的token后续完全靠token维持会话跟微信再没关系。后端拦截器的逻辑也很简单写一个Interceptor拦截所有/api/**请求除了login接口从请求头取token查缓存或数据库确认有效然后把用户信息塞进ThreadLocal。这一套东西写清楚论文里的“系统安全设计”和“会话管理”都有素材了。3.2 发起签到与完成签到的完整链路用我当时的实现来举例教师发起签到教师在小程序端选择今天要签到的课程。后端根据课程ID查出课程自带的经纬度、教室名称生成一条sign_task设置start_time为当前时间end_time为当前时间15分钟。前端页面展示签到码和二维码同时页面底部出现“实时签到进度”每10秒轮询一次后端更新已签到人数。这里为什么不直接推送给所有学生因为小程序不能主动给用户发消息只能用订阅消息且需要用户主动订阅触发。毕设阶段别在这个坑上纠缠老老实实用“学生打开小程序首页自动显示待签到任务”的方案体验稍弱但用户路径短答辩也能说通。学生完成签到学生进入首页看到“去签到”按钮。点击后小程序先检查定位权限没有权限就引导用户开启scope.userLocation授权。调wx.getLocation拿到当前经纬度同时启动页面级倒计时提示“请在10秒内完成提交”。小程序把经纬度、任务ID发给后端/api/sign/doSign。后端做四件事校验token得到学生身份 → 查sign_task判断是否在时间窗口内 → 计算距离判断是否在范围内 → 尝试插入sign_record如果唯一索引冲突就返回“已签到”。第5步这个顺序很重要先校验身份和时间再查距离。因为距离计算比查库耗时让不满足基本条件的学生快速失败能减轻并发情况下的数据库压力。3.3 防代签设计不能只靠定位要三层叠加课堂考勤最大的痛点是代签。只有定位还不够——学生完全可以叫室友拿着手机去教室代签。所以还要叠加两道保险签到码机制教师发起签到时生成随机4位数字签到码课堂大屏展示。学生签到时除了定位还要输入这4位码。这样即使人不在教室没有码也签不了。当然这个码会被教室里的学生传到群里所以只能防“不在教室也没人通风报信”的情况。时间窗口限制把签到窗口压缩到2分钟以内代签的人大概率来不及把码传出去。这个设计不需要额外工作量只要把sign_task.end_time - start_time控制在120秒即可但答辩时可以当成一个“防代签策略”讲。另外一个容易被问到的点是怎么识别学生中途退出小程序。小程序自带生命周期我们可以在签到页面的onHide里记录时间戳在onShow时判断离开时长超过30秒就提示“本次签到可能被标记为异常”。这个功能不复杂写在论文“系统特色”里却很加分因为微信官方文档没有直接给这个方案属于你主动思考的产物。3.4 统计与导出给论文里的“数据分析”撑场面签到记录攒到一周之后教师的统计页面需要做三件事按时出勤率、迟到率、缺勤率。计算公式其实很简单出勤率 正常签到次数 / 应签到次数迟到率 迟到次数 / 应签到次数缺勤率 应签到次数 - 签到次数/ 应签到次数注意缺勤率里要把“有请假审批通过”的排除掉不然数据不准。这个细节我在论文里单独画了一个“统计口径说明”小表格答辩老师看了觉得很严谨。数据导出用后端来写Excel即可Java后端推荐用阿里EasyExcel比Apache POI的API友好很多。小程序端导出流程前端请求导出接口 → 后端生成xlsx文件并返回下载地址 → 小程序用wx.downloadFile下载 → 用wx.openDocument打开预览。这个链路也是毕设里展示“前后端协作”的好素材记得把它写进论文的详细设计章。4. 源码整理与LW文档撰写把项目变成老师眼中的“优秀毕设”4.1 代码不是能跑就行目录结构、注释风格都要像样说句扎心话毕业设计答辩老师不一定有时间跑你的代码但他一定会翻你的源码目录。所以源码部分至少要整理成别人能看懂的工程结构后端按Spring Boot标准分包controller、service、mapper、entity、config、common。不要把业务逻辑全塞进Controller里一个Controller里十几个接口又没有分层老师翻两页就想关掉。接口返回结构统一定义一个ResultT类包含code、message、data三个字段。所有接口返回这个结构前端也统一处理这就是网上常说的“请求封装”哪怕你没封装的特别优雅至少后端接口格式得统一。注释不是越多越好而是在关键逻辑处写“为什么”。比如距离判断那里注释写一行// 使用Haversine公式计算球面距离精度约0.5%满足课堂签到需求一眼就知道你懂原理。小程序端建议在utils目录下封装一个request.js统一管理token注入、错误码提示、加载动画。这事很小但源码质量好不好看这个文件就知道。4.2 LW文档的“三图一表”套路很多同学下载了源码却不知道论文怎么下笔最后把千篇一律的模板抄一遍交上去。我建议LW文档坚持“三图一表”原则基本就能覆盖老师想看的内容系统架构图后端画成三层架构表现层→业务层→数据层小程序端画成“视图层→逻辑层→微信通信层”两端通过HTTP连接。这张图画好概要设计就赢了一半。业务流程图以“一次完整签到”为主线从学生打开小程序到签到成功把时间校验、距离校验、重复校验三个判断画成菱形分支。E-R图把用户、课程、签到任务、签到记录、请假这五张表的关系画出来标清一对多、多对多。数据库表结构表每张表列字段名、类型、约束、说明。这个表能直接看出工作量是论文最“实”的部分。写论文时最忌讳的是把代码原样贴上去。老师想看的不是代码本身而是你为什么这么设计。比如签到码机制你可以写“考虑到代签风险本系统在定位基础上增加了签到码校验签到码由教师端实时生成有效期为签到窗口内过期自动作废”这段话一百字比贴三段代码都管用。5. 开发踩坑实录定位、授权、联调那些破事儿5.1 定位不准模拟器里好好的真机上飘了我调试定位时遇到的最头疼问题是微信开发者工具的模拟器定位特别准地图一拖坐标就变了但上了真机尤其是室内教室环境GPS信号弱定位点经常飘到50米外直接把本来在教室的同学拒之门外。解决方案有两个方向一是把签到半径从50米放大到100米牺牲一点严格性换来可用性二是用到wx.getLocation的高精度模式wx.getLocation({ type: gcj02, isHighAccuracy: true, highAccuracyExpireTime: 3000 })这里必须说明type一定要写gcj02这是腾讯地图的坐标系如果你的后端地图插件用的是WGS84标准不转换坐标会偏移几百米这就是真正的“话不多说全白干”。5.2 用户拒绝授权签到功能直接卡死小程序定位必须先获得scope.userLocation授权。如果用户第一次点了拒绝之后wx.getLocation就会直接走fail回调很多同学就把fail回调里弹个toast“获取定位失败”草草了事。正确做法是先检查wx.getSetting里的授权状态如果是false调用wx.openSetting引导用户去设置页重新打开授权。这个坑在答辩演示当天最容易出糗老师递给你一台演示手机你一看定位权限没开整个流程断在第一屏。建议做完授权引导之后在真机上连续测试“拒绝—重新授权—再授权”至少五遍。5.3 域名白名单和后端联调预览版跑不通的真相小程序有个硬性限制真机预览时所有请求的域名必须在小程序后台配置为request合法域名且必须是HTTPS协议。这就意味着你本地联调的http://localhost:8080只能在小程序开发者工具里勾选“不校验合法域名”才能跑通但一发给同学测试通通失效。毕设阶段没有公网HTTPS域名怎么办两个常用方案内网穿透工具把你的本机服务映射成一个公网HTTPS地址临时测试够用。注意工具本身的配置要提前熟悉现场演示时最怕工具重启了忘了怎么再启动。云服务器部署买一台最便宜的云服务器部署Spring Boot再用Nginx配置SSL证书。这套流程听起来麻烦但做完之后你论文的“系统部署”章节就有东西写了而且“HTTPS证书配置”这句话本身就是加分项。还有一件事小程序体验版的分发。在微信开发者工具点“上传”代码就进了小程序后台变成了开发版然后到后台把它设为体验版生成体验版二维码发给同学扫码。这个流程你在答辩前一定要完整走一遍我见过太多人在这一步卡住因为小程序没有认证时体验成员名额有限得提前把测试者的微信号加进体验成员列表。5.4 并发场景全班同时签到把接口打崩一个50人的班级同时点签到如果后端没做任何控制数据库连接池不够用就会报超时。这个场景在毕设里不一定会被压测但答辩老师可能会问“如果100个人同时签到你的系统扛得住吗”你可以不做复杂优化但至少要在方案层面说出两点数据库层面sign_record表加(task_id, student_id)唯一索引重复插入直接走异常处理而不是先查再插。先查再插在并发下会出重复数据直接插靠唯一索引兜底才是正确姿势。服务层层面签到接口加上简单的Redis分布式锁键名可以是sign:taskId:studentId加锁失败就返回“请勿重复提交”。哪怕毕设没接Redis也能在防御性设计章节里提这个思路。写在最后的一点体会这个项目做完我最深的感觉是课堂考勤签到系统看着不难但把“签到”这个动作真正做好涉及的不只是CRUD还有定位算法、权限设计、并发兜底、异常分支每一项都值得在文档里好好展开。如果你手里已经有源码别急着改个名字就交先按我上面说的数据表结构和防代签逻辑过一遍该补的补该加的加。代码是死的但你是活的把项目变成你自己能讲清楚的东西答辩自然就稳了。最后再分享一个小经验论文里所有截图一定要用真机操作截图模拟器截图太假老师一眼就看出来你没跑过真机。祝顺利。
微信小程序课堂考勤签到系统：从选型到防代签的完整实现
做毕业设计选到这个题目的同学我太懂你了。“基于微信小程序的课堂考勤签到系统”乍一看就是个老掉牙的CRUD项目网上源码一抓一大把配套LW文档论文文档也有现成的。但我想说句实在话正因为这个题目太普遍老师一眼就能看出你是真做了还是纯凑合。我当年做同类项目时踩过的坑、答辩被追问的细节今天一次性给你讲清楚。这篇文章不打算给你罗列“完整源码”而是告诉你怎么把这个题目做成一个经得起追问的毕业设计从为什么选型、数据表怎么设计、签到流程怎么防代签到LW文档怎么写才能让老师觉得你有思考再到开发中那些真机测试才暴露的坑。无论你是准备自己撸代码还是手里已经有一份源码文档想改造成自己的东西这篇都能帮你少走很多弯路。1. 为什么毕业设计选这个题目读懂需求再动手比找源码重要得多1.1 这个题目到底在考察什么先拆一下题面。“基于微信小程序的课堂考勤签到系统”三个关键词微信小程序、课堂考勤、签到系统。翻译成毕设语言就是一套完整的前后端分离应用学生用微信小程序完成签到教师能发起签到、查看统计后台有数据管理能力。很多同学看到“源码文档”就兴奋觉得下载下来改个名字就能交差。但答辩老师不傻他随口问一句“你的签到时间校验逻辑写在哪一层”你就得能接住。这个题目的隐藏考点其实是这三个移动端适配小程序不是网页它有冷启动、授权流程、生命周期、审核机制这些都要体现在你的项目里。地理位置打卡课堂签到最常见的算法场景是基于经纬度的距离判断这是论文里能写、答辩能讲的“硬核点”。角色权限体系学生、教师、管理员三种角色怎么区分接口怎么防越权这是区分“会写代码”和“懂设计”的分水岭。另外还有一层隐性需求课堂签到要解决的是代签、晚到、统计繁琐这三个痛点。如果你的设计里没有针对其中任何一个给出可落地的方案那整个项目就是套壳。1.2 选型之前先把坑想明白我看到不少同学一上来就问“用原生小程序还是uniapp”“后端用Java还是Node”这种问题其实应该反过来问你的毕设周期有多长答辩老师偏好什么样的技术栈你本身哪块最熟。以我自己带过和做过的经验来看最稳妥的组合是前端微信小程序原生开发后端Spring BootJava数据库MySQL为什么不是uniapp不是它不好是原生小程序在毕设场景下出错更少、资料更全、答辩更好讲。uniapp多了一层编译转换真机调试时偶尔出一些莫名其妙的问题你还要额外解释“为什么跨端框架在微信上表现不稳定”等于给自己加戏。Spring Boot就更不用说了Java后端在计算机类毕设里占有率极高遇到问题搜一下全是对应方案而且老师大概率看得懂Java代码。另一个近年很流行的方案是微信云开发不用自己买服务器、不用配域名云函数直接读写云数据库。说实话做原型非常快但我劝你慎选。原因很现实毕设论文里“系统架构”那一章会让你很难写因为没有传统意义上的后端服务你没法画清晰的请求链路图。而且答辩老师如果有Java背景会一直追问“云函数的安全性怎么保证”反而容易翻车。用传统前后端分离论文素材最完整。2. 整体架构与核心设计一个人怎么把系统拆得明明白白2.1 功能模块拆分与页面清单拿到题目第一步不是写代码是画功能清单。别小看这一步你的LW文档第三章“需求分析”全靠它撑场面。我当时把系统拆成了三个端学生端小程序端微信登录通过wx.login获取code后端换openid建立账号体系课程签到查看当前待签到课程一键定位打卡签到记录按日期查看历史出勤列表支持分页加载请假申请提交请假原因等待教师审批教师端小程序端发起签到选择课程、设置签到时间窗口、自动携带课程地点坐标签到详情实时查看已签到/未签到名单支持迟到标记审批请假同意或驳回学生的请假申请出勤统计按课程/按时间维度查看出勤率管理端Web后台用户管理导入学生名单、教师名单重置密码课程管理绑定课程与教师、设置上课时间和地点数据看板全校出勤率趋势、各课程迟到率排行页面规划上小程序端我建议控制在8~10个页面以内太多了写不完太少了显得单薄。我的清单是登录页、首页课程列表、签到详情页、记录列表页、请假表单页、教师工作台、发起签到页、课程统计页、个人中心页。这里的技巧是页面数量不要追求多要把每个页面的交互讲清楚。比如首页课程列表不是简单的列表渲染需要区分“待签到”“已签到”“已迟到”三种状态卡片这是能写进论文的功能亮点。2.2 数据表设计这几张表决定了答辩时你能说多细数据库设计是LW文档“概要设计”的核心素材也是老师必看的内容。我总结了一套适合课堂考勤的最小但完整的表结构用户表sys_userid、openid、学号/工号、姓名、角色、头像、创建时间。openid必须加唯一索引这是小程序登录体系的锚点。课程表courseid、课程名、教师id、上课周次、开始时间、结束时间、教室ID。这里要和签到场景联动所以课程地点坐标latitude、longitude建议直接存在课程表里发起签到时直接从课程带上坐标。签到任务表sign_taskid、课程id、发起教师id、签到码、开始时间、结束时间、签到地点经纬度、允许签到的半径米、状态。这张表是最核心的因为“签到”在这里是一个可以复用的动作。签到记录表sign_recordid、任务id、学生id、签到时间、提交的经纬度、与签到地点的距离、签到状态正常/迟到、是否代签标记。这张表的唯一索引建议设置为task_id、student_id直接防止重复签到。请假表leave_requestid、学生id、课程id、请假原因、状态、审批时间。为什么要在这里反复强调索引因为答辩时如果老师问你“怎么防止一个学生签到两次”除了前端按钮置灰你还要说出“后端唯一索引兜底”这层设计。这才是真正体现你思考深度的地方。单个学生和课程是多对多的关系所以还要考虑学生选课表student_course这个表虽然简单但能撑起“用户-课程”关联建议也加上不然签到记录和课程对不上。2.3 定位签到的原理从经纬度到“距离小于50米”课堂考勤签到最核心的算法不是人脸识别也不是扫二维码这两个都能被绕过而是地理围栏签到。原理用大白话说教师在某个教室发起签到系统保存这个教室的经纬度坐标和签到范围半径比如50米。学生签到时小程序获取学生当前经纬度计算这两个经纬度的球面距离如果小于50米判定为“在教室”允许签到。球面距离不能直接用平面勾股定理算因为地球是个椭球体。行业常用的是Haversine公式a sin²(Δlat/2) cos(lat1) * cos(lat2) * sin²(Δlng/2) c 2 * atan2(√a, √(1−a)) distance R * c // R取6371km公式看着唬人其实就是把两点经纬度换算成球面上的弧长。后端Java里可以直接用Math库实现不用额外引依赖。如果你用的MySQL 5.7以上版本也可以用自带的st_distance_sphere函数但为了论文里能展示算法思路建议自己在Service层里写一遍别全交给数据库黑盒。除了距离判断还得加上时间判断。签到任务表里有开始时间和结束时间前端提交签到请求时后端要判断当前时间早于开始时间不在签到窗口当前时间在开始时间到开始10分钟内正常签到当前时间在开始10分钟之后到结束时间标记为迟到当前时间晚于结束时间拒绝签到这里有个很容易被忽略的细节前后端时间必须统一用时间戳或者标准时区我当时就吃过亏数据库存的是本地时间服务器部署在另一个时区导致签到窗口错乱了两个小时排查了一整天才发现。3. 核心流程实现登录、发签到、防代签的完整链路3.1 登录与Session管理wx.login的code到底怎么换openid微信小程序没有传统的“账号密码登录”它的标准流程是小程序端调用wx.login()拿到一个临时凭证code。小程序把code通过wx.request发给自己的后端接口比如POST /api/auth/login。后端拿着这个code去请求微信官方的code2Session接口拿到openid和session_key。后端用openid查用户表如果查不到说明是第一次使用自动注册查得到直接登录。后端自己生成一个token可以是UUID或者JWT返回给小程序。小程序把token存在wx.setStorageSync里后续所有请求头部带上这个token。这个流程里新手最容易犯的错是把code当成登录凭证反复用实际上code是一次性的五分钟内有效用一次就作废。正常的设计是后端用code换完openid之后就生成自己的token后续完全靠token维持会话跟微信再没关系。后端拦截器的逻辑也很简单写一个Interceptor拦截所有/api/**请求除了login接口从请求头取token查缓存或数据库确认有效然后把用户信息塞进ThreadLocal。这一套东西写清楚论文里的“系统安全设计”和“会话管理”都有素材了。3.2 发起签到与完成签到的完整链路用我当时的实现来举例教师发起签到教师在小程序端选择今天要签到的课程。后端根据课程ID查出课程自带的经纬度、教室名称生成一条sign_task设置start_time为当前时间end_time为当前时间15分钟。前端页面展示签到码和二维码同时页面底部出现“实时签到进度”每10秒轮询一次后端更新已签到人数。这里为什么不直接推送给所有学生因为小程序不能主动给用户发消息只能用订阅消息且需要用户主动订阅触发。毕设阶段别在这个坑上纠缠老老实实用“学生打开小程序首页自动显示待签到任务”的方案体验稍弱但用户路径短答辩也能说通。学生完成签到学生进入首页看到“去签到”按钮。点击后小程序先检查定位权限没有权限就引导用户开启scope.userLocation授权。调wx.getLocation拿到当前经纬度同时启动页面级倒计时提示“请在10秒内完成提交”。小程序把经纬度、任务ID发给后端/api/sign/doSign。后端做四件事校验token得到学生身份 → 查sign_task判断是否在时间窗口内 → 计算距离判断是否在范围内 → 尝试插入sign_record如果唯一索引冲突就返回“已签到”。第5步这个顺序很重要先校验身份和时间再查距离。因为距离计算比查库耗时让不满足基本条件的学生快速失败能减轻并发情况下的数据库压力。3.3 防代签设计不能只靠定位要三层叠加课堂考勤最大的痛点是代签。只有定位还不够——学生完全可以叫室友拿着手机去教室代签。所以还要叠加两道保险签到码机制教师发起签到时生成随机4位数字签到码课堂大屏展示。学生签到时除了定位还要输入这4位码。这样即使人不在教室没有码也签不了。当然这个码会被教室里的学生传到群里所以只能防“不在教室也没人通风报信”的情况。时间窗口限制把签到窗口压缩到2分钟以内代签的人大概率来不及把码传出去。这个设计不需要额外工作量只要把sign_task.end_time - start_time控制在120秒即可但答辩时可以当成一个“防代签策略”讲。另外一个容易被问到的点是怎么识别学生中途退出小程序。小程序自带生命周期我们可以在签到页面的onHide里记录时间戳在onShow时判断离开时长超过30秒就提示“本次签到可能被标记为异常”。这个功能不复杂写在论文“系统特色”里却很加分因为微信官方文档没有直接给这个方案属于你主动思考的产物。3.4 统计与导出给论文里的“数据分析”撑场面签到记录攒到一周之后教师的统计页面需要做三件事按时出勤率、迟到率、缺勤率。计算公式其实很简单出勤率 正常签到次数 / 应签到次数迟到率 迟到次数 / 应签到次数缺勤率 应签到次数 - 签到次数/ 应签到次数注意缺勤率里要把“有请假审批通过”的排除掉不然数据不准。这个细节我在论文里单独画了一个“统计口径说明”小表格答辩老师看了觉得很严谨。数据导出用后端来写Excel即可Java后端推荐用阿里EasyExcel比Apache POI的API友好很多。小程序端导出流程前端请求导出接口 → 后端生成xlsx文件并返回下载地址 → 小程序用wx.downloadFile下载 → 用wx.openDocument打开预览。这个链路也是毕设里展示“前后端协作”的好素材记得把它写进论文的详细设计章。4. 源码整理与LW文档撰写把项目变成老师眼中的“优秀毕设”4.1 代码不是能跑就行目录结构、注释风格都要像样说句扎心话毕业设计答辩老师不一定有时间跑你的代码但他一定会翻你的源码目录。所以源码部分至少要整理成别人能看懂的工程结构后端按Spring Boot标准分包controller、service、mapper、entity、config、common。不要把业务逻辑全塞进Controller里一个Controller里十几个接口又没有分层老师翻两页就想关掉。接口返回结构统一定义一个ResultT类包含code、message、data三个字段。所有接口返回这个结构前端也统一处理这就是网上常说的“请求封装”哪怕你没封装的特别优雅至少后端接口格式得统一。注释不是越多越好而是在关键逻辑处写“为什么”。比如距离判断那里注释写一行// 使用Haversine公式计算球面距离精度约0.5%满足课堂签到需求一眼就知道你懂原理。小程序端建议在utils目录下封装一个request.js统一管理token注入、错误码提示、加载动画。这事很小但源码质量好不好看这个文件就知道。4.2 LW文档的“三图一表”套路很多同学下载了源码却不知道论文怎么下笔最后把千篇一律的模板抄一遍交上去。我建议LW文档坚持“三图一表”原则基本就能覆盖老师想看的内容系统架构图后端画成三层架构表现层→业务层→数据层小程序端画成“视图层→逻辑层→微信通信层”两端通过HTTP连接。这张图画好概要设计就赢了一半。业务流程图以“一次完整签到”为主线从学生打开小程序到签到成功把时间校验、距离校验、重复校验三个判断画成菱形分支。E-R图把用户、课程、签到任务、签到记录、请假这五张表的关系画出来标清一对多、多对多。数据库表结构表每张表列字段名、类型、约束、说明。这个表能直接看出工作量是论文最“实”的部分。写论文时最忌讳的是把代码原样贴上去。老师想看的不是代码本身而是你为什么这么设计。比如签到码机制你可以写“考虑到代签风险本系统在定位基础上增加了签到码校验签到码由教师端实时生成有效期为签到窗口内过期自动作废”这段话一百字比贴三段代码都管用。5. 开发踩坑实录定位、授权、联调那些破事儿5.1 定位不准模拟器里好好的真机上飘了我调试定位时遇到的最头疼问题是微信开发者工具的模拟器定位特别准地图一拖坐标就变了但上了真机尤其是室内教室环境GPS信号弱定位点经常飘到50米外直接把本来在教室的同学拒之门外。解决方案有两个方向一是把签到半径从50米放大到100米牺牲一点严格性换来可用性二是用到wx.getLocation的高精度模式wx.getLocation({ type: gcj02, isHighAccuracy: true, highAccuracyExpireTime: 3000 })这里必须说明type一定要写gcj02这是腾讯地图的坐标系如果你的后端地图插件用的是WGS84标准不转换坐标会偏移几百米这就是真正的“话不多说全白干”。5.2 用户拒绝授权签到功能直接卡死小程序定位必须先获得scope.userLocation授权。如果用户第一次点了拒绝之后wx.getLocation就会直接走fail回调很多同学就把fail回调里弹个toast“获取定位失败”草草了事。正确做法是先检查wx.getSetting里的授权状态如果是false调用wx.openSetting引导用户去设置页重新打开授权。这个坑在答辩演示当天最容易出糗老师递给你一台演示手机你一看定位权限没开整个流程断在第一屏。建议做完授权引导之后在真机上连续测试“拒绝—重新授权—再授权”至少五遍。5.3 域名白名单和后端联调预览版跑不通的真相小程序有个硬性限制真机预览时所有请求的域名必须在小程序后台配置为request合法域名且必须是HTTPS协议。这就意味着你本地联调的http://localhost:8080只能在小程序开发者工具里勾选“不校验合法域名”才能跑通但一发给同学测试通通失效。毕设阶段没有公网HTTPS域名怎么办两个常用方案内网穿透工具把你的本机服务映射成一个公网HTTPS地址临时测试够用。注意工具本身的配置要提前熟悉现场演示时最怕工具重启了忘了怎么再启动。云服务器部署买一台最便宜的云服务器部署Spring Boot再用Nginx配置SSL证书。这套流程听起来麻烦但做完之后你论文的“系统部署”章节就有东西写了而且“HTTPS证书配置”这句话本身就是加分项。还有一件事小程序体验版的分发。在微信开发者工具点“上传”代码就进了小程序后台变成了开发版然后到后台把它设为体验版生成体验版二维码发给同学扫码。这个流程你在答辩前一定要完整走一遍我见过太多人在这一步卡住因为小程序没有认证时体验成员名额有限得提前把测试者的微信号加进体验成员列表。5.4 并发场景全班同时签到把接口打崩一个50人的班级同时点签到如果后端没做任何控制数据库连接池不够用就会报超时。这个场景在毕设里不一定会被压测但答辩老师可能会问“如果100个人同时签到你的系统扛得住吗”你可以不做复杂优化但至少要在方案层面说出两点数据库层面sign_record表加(task_id, student_id)唯一索引重复插入直接走异常处理而不是先查再插。先查再插在并发下会出重复数据直接插靠唯一索引兜底才是正确姿势。服务层层面签到接口加上简单的Redis分布式锁键名可以是sign:taskId:studentId加锁失败就返回“请勿重复提交”。哪怕毕设没接Redis也能在防御性设计章节里提这个思路。写在最后的一点体会这个项目做完我最深的感觉是课堂考勤签到系统看着不难但把“签到”这个动作真正做好涉及的不只是CRUD还有定位算法、权限设计、并发兜底、异常分支每一项都值得在文档里好好展开。如果你手里已经有源码别急着改个名字就交先按我上面说的数据表结构和防代签逻辑过一遍该补的补该加的加。代码是死的但你是活的把项目变成你自己能讲清楚的东西答辩自然就稳了。最后再分享一个小经验论文里所有截图一定要用真机操作截图模拟器截图太假老师一眼就看出来你没跑过真机。祝顺利。
