马拉松报名这个选题我隔壁学弟毕业设计做的就是它去年帮他改代码改到凌晨两点完工那一刻整个人是崩溃的但回头一看这套东西从技术深度到展示效果确实能打。微信小程序端报名、后台赛事管理、在线支付、参赛凭证生成全是完整闭环不是一个“教学demo”糊弄人。而这篇文章要做的就是把这个项目的核心设计、实现细节、踩坑记录和论文写法全盘拆给你如果你是做毕设或课设直接照这个思路走省下至少两周的调研时间。这个系统解决的是真实痛点马拉松赛事报名高峰期并发压力大、信息登记琐碎、报名状态不透明以及组委会管理线下数据极其痛苦。它通过小程序端完成用户注册登录、赛事浏览、在线报名、订单支付和电子参赛凭证展示后台端完成赛事发布、组别配置、人数限制、报名审核和数据统计从用户到管理端形成完整业务闭环。适合三种人正在找Java/小程序方向的毕设课题的在校生想系统了解小程序全栈开发流程的初级开发者以及需要一款可直接改装成任何活动报名系统跑步、骑行、讲座的技术参考人员。1. 项目整体设计与技术选型解析1.1 为什么选“马拉松报名”这个场景我见过太多毕设选题比如“XX管理系统”或者“XX商城”最大的问题就是业务逻辑太浅答辩时老师一问业务流程就卡壳了。马拉松报名系统好就好在它的业务模型天然具有复杂度赛事有多个组别全程、半程、迷你跑每个组别有独立的报名名额限制用户需要填写详细的个人信息部分赛事需要审核资质还有支付环节、取消报名、名额释放这一套流程做下来几乎覆盖了一个真实互联网产品的基础结构。另一个原因是数据模型有得写。用户表、赛事表、组别表、报名表、订单表、参赛卡表至少五六张核心表表与表之间有明确的外键关系和状态流转。这在论文的系统设计章节是最容易出内容的画E-R图、画架构图甚至写数据库优化的时候都有得展开不会出现“表太简单没东西写”的尴尬。而且从展示角度看小程序端的UI效果比传统Web管理后台好做得多首页赛事推荐、赛事详情、倒计时、报名进度条都有很直观的视觉冲击力答辩现场直接演示小程序比演示白底的网页后台有说服力得多。1.2 技术选型小程序端、服务端、数据库怎么搭先说我个人最推荐也是这类型项目用得最顺手的组合层级技术选型选择理由小程序端原生微信小程序不需要额外构建链微信开发者工具直接跑API最全出错容易排查服务端Spring Boot 2.7 MyBatis-Plus生态成熟REST API开发效率高事务和拦截器写起来省事数据库MySQL 8.0表关系清晰事务支持稳定毕设环境部署最简单鉴权方案JWTToken无状态鉴权小程序端存储token方便不需要session同步支付微信支付V3按官方文档接入预支付接口适合毕设展示真实业务闭环有人会问为什么不用uni-appuni-app确实能一套代码多端复用但要考虑到你的时间是有限的原生小程序的调试比uni-app少很多坑比如导航栏、分享、支付回调这些原生能力官方文档直接查就好。uni-app的报错经常是“编译层运行层”双重问题答辩现场一紧张根本来不及排查。服务端用Spring Boot是因为Java相关技术栈在论文里最好写用户量、并发处理、事务隔离这些术语老师都爱听。如果你更熟悉Node.js用Express或Egg也不是不行但要注意MyBatis-Plus的代码生成器、分页插件这些省力工具只有Java这边有开发效率差距不是一星半点。1.3 系统架构与核心角色拆解整个系统分三条链路用户链路注册/登录 → 浏览赛事列表 → 查看赛事详情 → 选择组别并填写报名信息 → 创建订单并支付 → 生成电子参赛凭证 → 赛事开始当天展示凭证领取物料。管理链路管理员登录 → 创建赛事设置名称、时间、地点、组别、名额、报名费用 → 发布赛事 → 管理报名记录审核/导出 → 查看报名统计数据。数据链路小程序端调用HTTPS接口 → Spring Boot处理业务逻辑 → MyBatis操作MySQL → 返回统一JSON结构 → 小程序端渲染关键操作如支付回调通过微信支付平台回调通知触达状态更新。这三条链路缺一个这系统就不完整。很多学生只做了用户端报名后台就一个简单列表老师一问“赛事是谁创建的赛事信息怎么管理”就答不上来。所以后台管理端一定是必做项用电商后台改个皮都行但必须有一块能改赛事信息和看报名人数的管理界面。1.4 核心数据库表设计与字段规划数据库设计是整个项目的地基。我的建议是至少设计如下六张表并且一定要包含状态字段后续业务流程全靠状态机转换-- 用户表 CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) UNIQUE NOT NULL, -- 微信唯一标识 nickname VARCHAR(64) DEFAULT , avatar_url VARCHAR(255) DEFAULT , phone VARCHAR(20) DEFAULT , -- 手机号 id_card VARCHAR(18) DEFAULT , -- 身份证号 emergency_contact VARCHAR(20) DEFAULT , -- 紧急联系人 create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 赛事表 CREATE TABLE marathon ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, city VARCHAR(64) NOT NULL, start_date DATE NOT NULL, start_time VARCHAR(16) NOT NULL, location VARCHAR(255) NOT NULL, description TEXT, cover_url VARCHAR(255), status TINYINT DEFAULT 0, -- 0未发布 1报名中 2已截止 3已结束 create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 组别表一场赛事下挂多个组别 CREATE TABLE marathon_group ( id INT PRIMARY KEY AUTO_INCREMENT, marathon_id INT NOT NULL, group_name VARCHAR(32) NOT NULL, -- 全程/半程/迷你跑 distance DECIMAL(6,2) NOT NULL, -- 距离(公里) fee DECIMAL(8,2) NOT NULL, -- 报名费 quota INT NOT NULL, -- 名额总数 registered INT DEFAULT 0, -- 已报名数 start_time VARCHAR(16) NOT NULL -- 该组别起跑时间 ); -- 报名表 CREATE TABLE registration ( id INT PRIMARY KEY AUTO_INCREMENT, marathon_id INT NOT NULL, group_id INT NOT NULL, user_id INT NOT NULL, real_name VARCHAR(32) NOT NULL, phone VARCHAR(20) NOT NULL, id_card VARCHAR(18) NOT NULL, blood_type VARCHAR(4) DEFAULT , emergency_contact VARCHAR(32) NOT NULL, emergency_phone VARCHAR(20) NOT NULL, status TINYINT DEFAULT 0, -- 0待支付 1已支付 2已取消 3已退款 create_time DATETIME DEFAULT CURRENT_TIMESTAMP );关键是报名表里的registered字段它在业务上不是简单地自增而是要跟事务、锁结合起来防止并发超卖。这个细节论文的高质量章节就要从这里出。2. 代码结构与核心模块实现细节2.1 项目目录结构怎么组织代码才不会乱项目源码的目录结构一定要清晰老师打开GitHub仓库的时候第一眼就看这个。我推荐的布局如下marathon-system/ ├── miniprogram/ # 微信小程序端 │ ├── pages/ │ │ ├── index/ # 首页-赛事列表 │ │ ├── detail/ # 赛事详情 │ │ ├── register/ # 在线报名 │ │ ├── order/ # 订单确认/支付 │ │ ├── my/ # 个人中心 │ │ └── myRegister/ # 我的报名 │ ├── utils/ │ │ ├── request.js # 封装wx.request │ │ ├── auth.js # token管理 │ │ └── format.js # 时间/金额格式化 │ ├── app.js │ ├── app.json │ └── app.wxss ├── server/ # Spring Boot后端 │ ├── src/main/java/com/marathon/ │ │ ├── controller/ # 接口层 │ │ ├── service/ # 业务逻辑层 │ │ ├── mapper/ # MyBatis数据访问层 │ │ ├── entity/ # 实体类 │ │ ├── common/ # 统一返回、异常处理 │ │ └── config/ # 拦截器、Web配置 │ └── src/main/resources/ │ ├── mapper/ # XML文件 │ └── application.yml ├── admin/ # 后台管理端Vue或简化版 └── sql/ └── init.sql # 建库建表脚本2.2 登录注册wx.login 的完整流程与token签发微信小程序的登录是最容易写错的地方。核心流程是这样小程序端调用wx.login()获取临时code5分钟有效。把code发给后端后端调用微信官方接口code2Session换取 openid 和 session_key。后端根据 openid 查用户表如果没有就自动注册新用户有就直接返回已有用户。后端用openid作为payload签发JWT设置7天有效期返回token给小程序端。小程序端把token存入wx.setStorageSync(token, ...)后续请求头带Authorization: Bearer token。关键注意点这里不要用 session_key 作为登录凭证session_key 只用于解密敏感信息比如手机号快速验证。很多新手会混淆正确做法是openid JWT。// 后端 LoginController 核心逻辑简化版 PostMapping(/api/auth/login) public Result login(RequestBody LoginDTO dto) { // 1. 调用微信接口获取openid String openid wxService.code2Session(dto.getCode()); // 2. 查询用户 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); // 自动注册 } // 3. 签发JWT String token JwtUtil.generateToken(user.getId(), openid); return Result.success(token); }2.3 赛事浏览与首页推荐首页推荐列表的设计要抓住一个核心逻辑状态优先。报名的核心驱动是“现在能不能报”所以推荐逻辑状态为报名中status1的赛事排在前面发布时间倒序排。// 列表查询带分页 GetMapping(/api/marathon/list) public Result list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size, RequestParam(required false) String city, RequestParam(required false) Integer status) { PageMarathon p new Page(page, size); LambdaQueryWrapperMarathon wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(city), Marathon::getCity, city) .eq(status ! null, Marathon::getStatus, status) .orderByDesc(Marathon::getStartDate); return Result.success(marathonService.page(p, wrapper)); }2.4 在线报名核心流程事务、锁与状态机报名是整个系统的核心高光模块也是最容易出并发bug的地方。基础流程分四步校验赛事状态必须是“报名中”组别还有名额用户没有重复报名。扣减名额UPDATE marathon_group SET registered registered 1 WHERE id ? AND registered quota。创建报名记录状态为“待支付”并创建订单记录。支付对接微信支付预支付接口用户在小程序端完成支付后端收到支付回调后更新状态为“已支付”生成参赛资格记录。这里的核心是第2步不加锁支持的代码在报名高峰会“超卖”——两个人同时看到有名额都提交了最后名额被扣成负数。解决办法有两个方向乐观锁方案用版本号字段控制UPDATE marathon_group SET registered registered 1, version version 1 WHERE id ? AND registered quota AND version ?如果影响行数为0说明名额已被抢走或者版本冲突提示“名额不足”重新查询最新名额。悲观锁方案查询时SELECT ... FOR UPDATE锁住该组别记录直到事务结束简单粗暴但性能稍差对于毕设和中小型赛事完全够用。我在实际实现中组合了这两种方式先乐观锁更新再用事务包裹创建报名表订单表保证要么全部成功、要么全部回滚。2.5 个人中心我的报名与参赛凭证我的报名页要支持按状态筛选待支付、已报名、已取消。待支付的要给一个“去支付”按钮并带一个15分钟倒计时订单超时自动取消并释放名额这个倒计时不仅提升真实感也把“超时订单处理”变成了论文里的一个业务亮点。// 小程序端订单倒计时实现15分钟 Page({ data: { countdown: 900 }, startCountdown(deadline) { const timer setInterval(() { const remain Math.max(0, deadline - Date.now()); if (remain 0) { clearInterval(timer); this.cancelOrder(); // 超时自动取消 } this.setData({ countdown: remain }); }, 1000); } });参赛凭证的展示用一个小设计让答辩时加分生成一张模拟的电子号码牌显示参赛号、姓名、组别、二维码二维码内容可以用赛事ID报名ID拼接后加密。不用真的做得很复杂但视觉上要像那么回事。3. 小程序端关键交互与踩坑记录3.1 顶部导航栏高度与安全区适配作为一个经常和微信小程序UI较劲的人我可以负责任地说导航栏高度适配是新手最容易栽的坑。小程序中导航栏由“状态栏手机最上方电量时间区域 导航栏标题区域”组成其中状态栏高度在不同机型下不同iPhone 14 Pro 大概50px普通安卓约24px导航栏高度在胶囊按钮附近跟着机型变化。如果直接写死48pxiPhone上标题会顶到状态栏里丑到没法看。正确做法是// app.js 全局获取系统信息 const system wx.getWindowInfo(); const menu wx.getMenuButtonBoundingClientRect(); // 导航栏总高度 (胶囊底边距顶部距离 - 状态栏高度) * 2 胶囊高度 状态栏高度 this.globalData.navBarHeight (menu.top - system.statusBarHeight) * 2 menu.height; this.globalData.statusBarHeight system.statusBarHeight;这一步做完后导航栏区域才能用 padding-top 填充状态栏高度 自定义导航栏标题。如果不做适配在答辩现场用iPhone和安卓各演示一次就会出现明显差异非常影响。3.2 列表加载更多触底翻页与防重复加载首页赛事列表和报名记录都用“下拉刷新触底加载更多”的经典模式。这里有个关键技巧是请求防重当上一次请求还没返回时用户连续快速触发触底会导致发出三四个冗余请求前两个请求page2回来后又触发page3、page4数据重复显示。我使用的方案Page({ data: { page: 1, list: [], loading: false, finished: false }, onReachBottom() { if (this.data.loading || this.data.finished) return; this.setData({ loading: true }); this.loadList(); }, async loadList() { const res await request({ url: /api/marathon/list, data: { page: this.data.page, size: 10 } }); const list this.data.list.concat(res.records); this.setData({ list, loading: false, finished: res.total list.length, page: this.data.page 1 }); } });finished这个标志至少省了以后几十个无效请求。3.3 表单校验报名信息页的常见坑报名信息页是最容易让用户骂娘的页面。字段涉及姓名、手机号、身份证号、血型、紧急联系人等校验不到位会直接导致后端存储脏数据。手机号正则/^1[3-9]\d{9}$/身份证正则/^\d{17}[\dXx]$/顺便做性别判断18位身份证倒数第二位奇数男偶数女血型用picker选择器而不是输入框减少脏数据。两个特别注意一是身份证号里的x要处理大小写后端统一转大写避免同一身份证两种存法导致重复报名判断失效。二是紧急联系人手机号要和本人手机号做一个“不相同”的校验提醒这个细节容易漏但特别实用。3.4 登录态过期与 wx.checkSessionJWT的token默认7天过期但微信登录凭证session_key的有效期跟appid的配置有关有时用户长时间不打开小程序会把登录态状态搞乱。为兼容我在每次启动小程序时这样处理先看本地有没有token有token → 调一个/api/auth/verify接口验证token有效性token过期返回401 → 静默调用wx.login()重新获取code并换新token不让用户重复点登录如果是真·未登录状态才引导到登录页。实测下来这个“静默续期”的逻辑能大幅减少用户从常用入口点进来后的流失答辩时老师也会觉得细节做得到位。3.5 图片上传与扫描身份证组件报名页面里如果要做“身份证识别自动填充”小程序端可以用wx.chooseMedia调起相机或相册把图片先传到自己服务器的临时接口后端接OCR服务比如腾讯云OCR识别身份证号、姓名等字段识别结果回填到报名表单。这个功能不是核心必需但加上后确实能给答辩加分因为它体现了你了解“端上采集云端识别”的协作模式。注意两个坑上传接口要限制文件大小约2MB以内不然弱网环境上传时间会二三十秒体验很差OCR识别结果一定有置信度字段低于阈值就不要回填弹窗让用户手输更稳妥。4. 服务端接口设计与数据库调优4.1 接口设计规范这么做很省事服务端接口的整洁程度老师阅码无数打开Controller一眼就能判断水平。遵循这几个原则统一前缀所有接口以 /api 开头管理端以 /api/admin 开头清晰区分前后台权限。统一返回格式{ code: 200, message: success, data: {} }全局异常处理用RestControllerAdvice统一拦截业务异常、参数校验异常和未知异常避免直接把Java堆栈错误抛给小程序端。HTTP状态码与业务码分离HTTP 200代表请求到达了后端业务码200代表业务成功401代表token失效500代表业务异常528代表“名额不足”等业务错误。这样小程序端可以根据业务码做对应的UI反馈而不用每次解析后端的状态码。这套规范最大的好处是后期接管理后台时接口可以复用不用重写。4.2 拦截器与接口鉴权在Spring Boot中写一个AuthInterceptor实现Token校验Component public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) { String token req.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims ! null) { req.setAttribute(userId, claims.get(userId)); return true; } } res.setStatus(401); return false; } }需要“放行”的接口如赛事列表页、赛事详情页用白名单模式配置在/api/auth/**和部分GET接口中。这个设计不仅在代码层面解决权限问题论文中还能展开写“接口安全设计”一举两得。4.3 索引设计与SQL优化实战报名高峰期数据库最怕两种慢查询全表扫描和锁等待。实操上我做了三件事第一给核心字段加索引。marathon_group(marathon_id)、registration(user_id)、registration(marathon_id)、user(openid)、orders(order_no)全部建索引查询效率提升肉眼可见。第二报名数量统计走缓存。如果赛事详情页每次打开都去数SELECT COUNT(*) FROM registration WHERE ...数据量大了会很慢。项目里我用Caffeine本地缓存 TTL 60秒每场赛事缓存一个报名人数60秒刷新一次真实报名数字偏差控制在60秒内即可接受。第三导出报名数据用异步任务。管理端导出报名Excel如果同步做接口会等很久。简单做法提交导出请求后立即返回“导出中”后台用线程池执行导出完成后把文件放在服务器把下载链接通过消息推送通知管理员。这个细节就是论文里“系统优化”章节的真实素材。4.4 数据库防重复与数据一致性重复报名这个场景特别现实同一个用户对着同一个组别刷新两次就提交了。光靠前端按钮防抖挡不住聪明人绕过前端后端必须兜底-- 报名表加唯一约束用户组别 ALTER TABLE registration ADD UNIQUE KEY uk_user_group (user_id, group_id);有了这个唯一键数据库层面就限制了重复后端只要捕获DuplicateKeyException并返回友好提示“您已报名该组别”即可。这样做比业务代码判断更稳因为在高并发下业务判断存在“先查再插”的竞态窗口而数据库唯一约束是原子性的。5. 论文写作要点与答辩准备5.1 论文目录结构与每一章怎么写毕业设计的论文结构基本是有套路的我的建议是按下面这个目录走亲测老师认可度高绪论研究背景与意义马拉松赛事爆发数字化报名需求、国内外研究现状、主要工作。相关技术介绍微信开发者工具、Spring Boot、MyBatis-Plus、MySQL、JWT。系统需求分析可行性分析技术/经济/操作、功能需求用户端/管理端、非功能需求性能/安全/可用性。系统总体设计系统架构图、功能模块划分、数据库设计E-R图表结构说明。系统详细设计与实现核心模块流程、类图、接口设计、关键代码展示。系统测试测试方案、功能测试用例表、性能测试结果、兼容性测试。总结与展望。5.2 需求分析怎么写才不空需求分析是论文里最容易被老师批“太空”的部分。要写实建议用“用例描述”的方式用例用户在线报名主角色普通用户前置条件已登录、赛事状态为报名中、名额未满基本流用户选择组别 → 填写报名信息 → 确认订单 → 支付 → 生成参赛凭证异常流名额已满提示并返回、支付超时自动取消订单并释放名额、重复报名提示已报名把每一个核心业务流程都写成“用例图用例描述”需求分析章节立刻有了厚度。光说“系统支持在线报名功能”这种话三行就被老师打回但用例描述能写四五页。5.3 系统测试与用例表论文的测试环节很多人写得很水就一句“系统测试通过功能正常”。这是巨大减分项。写测试的关键是用例表用例编号测试模块测试步骤预期结果实际结果是否通过TC-001用户登录首次使用微信授权登录自动注册并跳转首页与预期一致通过TC-002在线报名选择“半程马拉松”填写信息并支付报名成功生成参赛凭证与预期一致通过TC-003名额超卖并发10个请求同时抢最后1个名额只有1个成功其余提示名额不足与预期一致通过TC-004订单超时创建订单后15分钟内不支付订单自动取消名额释放与预期一致通过其中TC-003最能体现系统质量也是答辩时的亮点。用JMeter或写一段并发测试代码跑一下把结果截图放进论文非常有说服力。5.4 答辩高频问题预判经验之谈下面这几个问题出现频率极高提前准备Q1为什么不用小程序云开发答本系统需要管理端权限控制和Excel导出等复杂业务自建后端架构更灵活云开发数据权限模型在处理复杂事务时约束较多。Q2如何处理并发下名额超卖答数据库唯一约束 乐观锁控制名额扣减 事务保证数据一致性。展开讲代码实现即可。Q3JWT过期了怎么办答过期后请求返回401小程序端拦截401后调用后端续期接口通过refresh_token换新token或静默重新login。我会明确区分两种方案的使用场景。Q4报名信息涉及身份证怎么保证安全答HTTPS传输、后端存储加密身份证号采用AES加密、日志中不打印明文身份证、管理端导出Excel时校验管理员身份。6. 项目扩展方向与个人经验如果是想把项目做得更出彩或者为论文“展望”章节积累素材下面几个方向值得考虑赛事地图与导航接入腾讯位置服务在赛事详情页展示起终点地图、配速路线规划配合路线海拔剖面图做可视化。成绩查询与电子完赛证书赛事结束后跑者输入参赛号即可查询成绩系统根据枪声成绩和净成绩生成可分享的电子完赛证书这是跑圈用户非常强烈的传播需求。消息推送通过订阅消息在赛事审核通过、报名成功、赛事临近开跑时给用户推送提醒。订阅消息是一次性的所以要在合适的时机如报名成功后让用户点一下订阅效果比一直发模板消息好。赛事直播与实时动态接入高德或百度的实时坐标接口做一个赛事直播页面观众可以看到亲友跑到哪里了。对毕设来说这个功能可以做简化版——跑者到打卡点扫码后更新位置。技术栈升级如果时间充裕可以尝试用uni-app重构小程序端跑通多端发布服务端做微服务化升级认证服务、赛事服务、订单服务拆分。就我个人体会马拉松报名系统是一个“麻雀虽小五脏俱全”的课题它不冷门、不偏门但只要你把业务闭环完整实现该有的并发、事务、安全、优化都有得聊。做这类项目最忌讳的不是代码写得烂而是“没有把业务闭环做完”——用户报了名查不了订单、订单付了款没有凭证、赛事发布不了。先把主流程走通再谈优化这是最实在的一条经验。