最近好几个学弟学妹来找我看毕业设计题目都指向同一个方向——基于小程序的篮球场馆预订系统。这个题目在计算机毕业设计里确实属于典型的“业务闭环完整、前后端都有、小程序端自带亮点”的选题网上能找到不少现成的源码工程配套的LW文档也就是设计说明文档/论文也基本形成了一套成熟模板。这篇文章不是单纯给你贴一段代码然后说“能跑就行”而是沿着“拿到源码 → 读懂设计 → 改造成自己的 → 写出文档 → 顺利答辩”这条完整路线把这个系统里真正重要的业务逻辑、数据库设计、踩坑点一次讲透。1. 项目整体设计与技术选型1.1 系统核心功能拆解一个合格的篮球场馆预订系统业务上至少要覆盖用户端小程序、后台管理系统、支付与退款流程、场地状态管理四大部分。用户端主要做这些事微信登录和手机号授权、浏览场馆列表、查看场地详情、选择日期时段、创建订单、微信支付、取消订单、查看我的订单以及入场核销。管理端则负责场馆管理、场地管理、批量生成场次、订单管理、退款审核、数据统计和用户管理。这些功能听起来常规但真正动手时你会发现一个“待支付、已支付、已入场、已取消、已退款”的状态流转加上并发抢场、超时释放、退款回调已经能把一个学生的代码能力考得明明白白。之所以推荐这个题目就是因为它把“资源预订”这一类业务的核心矛盾——“同一时间段场地不能被重复预订”——用最简单直观的形式呈现出来了非常适合作为计算机毕业设计的业务主线。1.2 为什么选小程序而不是H5或App作为毕业设计选题小程序端的优势非常明显。演示时评委直接拿微信扫码就能打开完全不需要安装APK开发成本也比原生App低很多一套wxml/wxss/javascript代码就能覆盖iOS和Android最关键的是微信生态里现成的登录、支付、订阅消息能力正好对应预订系统的完整闭环。如果做成H5网页虽然也能实现功能但演示时你得先准备域名、HTTPS证书而且评委还得打开浏览器输地址体验差很多。小程序虽然在真机预览时也需要域名但开发者工具里勾选“不校验合法域名”后本地开发阶段完全可以跑通不要求你一开始就买服务器和域名。这对绝大多数学生来说省下了真金白银也让前期开发的阻力小很多。1.3 技术栈与部署结构不同源码包的技术选型会有些差异但主流组合大致是这样的端常用技术小程序端微信小程序原生 / uni-app后台管理端Vue Element-UI / Layui jQuery后端服务Spring Boot / SSM / Node.js Express数据库MySQL 5.7 或 8.0接口风格RESTful JSON鉴权方式JWT 或微信 session_key拿到一个源码压缩包之后千万不要急着点启动。我通常按下面的顺序排查结构先看根目录有没有README或部署说明再找项目里的数据库SQL脚本接着看后端配置文件里的数据库连接和端口最后分别启动后端、管理端、小程序端。很多时候所谓的“跑不起来”不是代码问题而是配置文件里的数据库密码没改、字符集不对、端口被占用这些问题按顺序排查一遍就能解决。2. 数据库设计与核心业务逻辑2.1 核心数据表设计篮球场馆预订系统的数据库表通常有这样几张user 用户表openid、nickname、phone、avatar、create_timevenue 场馆表name、address、image、description、open_time、close_timecourt 场地表venue_id、name、type半场/全场、price_per_hourcourt_schedule 场次表court_id、date、start_time、end_time、status、pricebooking_order 订单表order_no、user_id、court_id、schedule_id、booking_date、start_time、end_time、amount、status、pay_time、refund_timerefund_record 退款记录表order_id、reason、status、operate_time有些简单教程会把场次信息直接塞进订单表只记录日期和时段然后靠SQL查重判断是否冲突。这个方案能跑通但扩展性很差因为篮球馆不同时段的价格很可能不同工作日晚上和周末价格不一样同一个场地在不同日期也可能临时调价。单独拆一张court_schedule表后台可以灵活配置每个时段的开放状态和价格这才符合真实场馆运营的逻辑。2.2 预订冲突处理与状态机预算冲突是整个系统的核心难点。用户在页面选好“2号场地周五20:00到21:00”点击提交时后端不能只查一次“该时段有没有订单”因为两个用户可能同时读到“没有订单”然后同时插入订单最后超卖。正确的做法有两种。第一种是“原子更新状态标记”直接对场次表做条件更新UPDATE court_schedule SET status 1 WHERE id #{scheduleId} AND status 0;如果更新影响的行数是1说明当前用户成功锁定了这个场次继续创建订单如果返回0说明场次已经被抢走直接提示“该时段已被预订”。这种写法实现简单对本科毕设来说已经完全够用。第二种是事务加行锁在MySQL里用SELECT ... FOR UPDATE锁住对应场次记录再判断状态并插入订单最后提交事务。这种方案控制粒度更细但代码复杂度高一些也容易出现死锁建议只在扩展功能时考虑。订单状态建议统一用int字段表示0待支付、1已支付、2已入场、3已取消、4已退款。要注意“已取消”和“已退款”的区别已取消是用户未支付或超时未支付系统自动关闭已退款是用户支付成功后又申请了退款钱原路退回。这两个状态如果混在一起后台统计营收时会出大问题。2.3 支付与退款流程设计微信支付接入对许多学生来说是最容易卡住的环节。很多网上下载的源码里用的是“模拟支付”也就是点击支付后直接调一个后端接口把订单状态改成已支付绕过了微信支付服务器。本地演示没问题但如果答辩老师当场要求扫码就可能会露馅。我的建议是如果时间允许尽量接微信小程序支付。流程是后端调用微信支付统一下单接口拿到支付参数小程序调wx.requestPayment拉起收银台支付结果通过回调通知后端更新订单状态。这个流程涉及到商户号、AppID、商户API密钥等配置申请周期较长所以如果实在来不及在LW文档里明确写清楚“当前使用模拟支付环境接口结构已按微信支付标准预留”答辩时诚实说明反而不会扣分。退款功能一般放在管理端管理员审核退款申请后后端调用微信支付退款接口成功后更新订单状态并写入退款记录。这里要注意退款金额不能大于订单实付金额退款原因不能为空微信支付接口证书要配置正确否则会报“证书校验失败”之类的问题。3. 小程序端实操要点3.1 登录、手机号授权与token处理小程序登录的标准流程是这样先用wx.login拿到code把code发给后端后端拿code向微信接口换取openid和session_key然后后端自己生成一份token返回给小程序。小程序收到token后存入storage后续所有业务请求都带上这个token请求头。服务端通过token识别用户身份不需要每次请求都去微信接口校验。手机号授权这一块现在新版小程序已经改成了button open-typegetPhoneNumber组件用户同意后后端通过code换手机号。很多旧源码还在用wx.getUserProfile拿昵称头像这部分逻辑很可能会失效所以拿到源码之后第一件事就是检查登录和用户信息获取这里是否还能跑通。如果只想快点完成毕设可以给用户表加上“模拟登录”按钮直接指定一个测试用户ID绕过微信登录的繁琐限制演示时再走一遍真实wx.login这样就比较稳妥。3.2 场地选择与时段日历组件小程序端的核心页面是场地预订页。通常的进法是场馆列表 → 点击场馆 → 进入场馆详情 → 选择日期和时段 → 确认订单。日期选择我习惯用横向滚动的七天日期条用scroll-view实现每个日期显示“周一 03-08”这样的格式点击后切换日期。时段网格则把一天按半小时或一小时切成多个时间段已预约的格子置灰可预约的格子高亮。这里有一个特别容易踩的坑日期计算千万别用字符串拼接。比如“2025-03-08”减一天不能直接解析字符串后减1跨月时会出问题。要么用时间戳计算要么用dayjs或moment这样的工具库统一处理。另一个坑是价格一定要以后端返回为准小程序端不要自己算总价否则后台改价之后前端页面价格和后端不一致会出现订单金额对不上的问题。3.3 订单创建与支付集成用户选好时段后点击“立即预约”小程序端不能直接提交订单先进确认订单页。确认页展示场馆、场地、日期、时间、金额用户补充联系手机号和入场人数后再点提交。提交时调用后端创建订单接口后端锁场次并生成待支付订单然后返回支付参数。到这里有一个顺序问题必须注意一定是先锁场次再创建订单最后支付。如果把支付放在锁场次之前就会导致用户支付成功却抢不到场地或者用户关闭支付页面后场次还被锁住形成死单。解决死单的常用办法是给订单表加created_at字段后端做定时任务把超过15分钟未支付的待支付订单主动关闭并释放对应场次。这个定时任务虽然不起眼但写进LW文档里非常加分因为它体现了“可用性设计”的思考。3.4 入场核销与订阅消息入场环节通常是在“我的订单”里展示一个二维码管理员在后台扫描或输入核销码确认入场。如果嫌二维码生成麻烦可以让订单号直接作为核销码后台输入订单号后四位即可核销简单有效。订阅消息也是个不错的亮点。用户支付成功后小程序通过wx.requestSubscribeMessage申请一次性订阅消息授权后端在开场前通过接口向用户发送一条提醒。虽然一次性订阅消息只能发一次但“支付成功申请订阅 → 开场前发送提醒”这个闭环正好合理。答辩时把这个功能讲清楚能在系统完整度上加分不少。4. 后台管理系统与LW文档写作4.1 管理端功能怎么划分管理后台是整个系统里相对容易被忽略的部分但它的工作量一点也不小。常见模块包括仪表盘、场馆管理、场地管理、场次管理、订单管理、用户管理和系统设置。仪表盘要展示今日订单数、营收、场地利用率等统计指标这些统计SQL其实不难写但很多源码里只是放了一些静态假数据。如果想把项目做得更扎实建议让统计接口从订单表实时聚合哪怕数据量不大效果也远好过写死数字。“批量生成场次”这个功能强烈建议保留并搞懂。管理员在后台设置“生成本周场次”系统自动为每个场地创建未来7天每个时段的court_schedule记录。这个功能不仅是运营的真实需求答辩时现场演示“一键排场”也会让老师觉得系统完整度高。4.2 管理端与小程序的接口设计接口设计最好采用RESTful风格路径清晰一点GET /api/venue/list 场馆列表GET /api/venue/{id} 场馆详情GET /api/court/schedule?courtIddate 查询某天场次POST /api/order/create 创建订单POST /api/order/pay 支付订单POST /api/order/cancel 取消订单GET /api/admin/order/list 管理端订单列表POST /api/admin/order/refund 退款审核管理端接口必须做角色鉴权不能裸奔。网上很多毕设源码的后台接口不校验身份任何人拿到接口路径都能调这在答辩时是明显的技术漏洞。用Spring Boot的话可以在JWT里增加role字段拦截器统一判断管理员角色实现成本很低但整体安全性和专业性会明显提升。4.3 LW文档快速成稿思路LW文档对很多同学来说是比代码更痛苦的东西。其实只要结构清晰写起来并不难。通常展开成这几章绪论项目背景、国内外研究现状、研究意义、论文结构需求分析功能性需求、非功能需求、用例图系统设计架构图、功能模块图、数据库ER图、接口设计系统实现每个功能模块的截图、核心代码片段、实现思路系统测试测试环境、功能测试用例、结论总结与展望。写作时有三个核心原则第一图表不能少ER图、用例图、时序图、部署图是支撑篇幅和“专业感”的关键第二文档内容必须和源码保持一致字段名、接口路径、业务流程都不能对不上否则答辩时老师随便一问就穿帮第三体验过程要写透用“用户从打开小程序到完成入场”的完整流程文字描述比空谈架构更能让人信服。5. 常见问题与排查技巧实录5.1 小程序请求后端失败页面空白这类问题十有八九出在域名和端口上。开发者工具里需要在“详情-本地设置”勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”。而后端地址不能写localhost尤其是真机调试时手机上的localhost指向手机自己根本不可能是你的电脑。这种情况要把baseURL改成电脑的局域网IP比如http://192.168.1.101:8080。我之前帮一个学弟排查他的后端接口在浏览器里访问完全正常小程序模拟器也能通唯独真机上一片空白。最后发现就是localhost惹的祸改成局域网IP后立刻就好了。如果后端部署在远程服务器上还要注意服务器防火墙端口是否开放云服务器的安全组规则也要允许对应端口入站。5.2 同一时段并发预订出现超卖这个问题容易出现在“先查询再插入”的写法里。两个请求同时查到场次状态为0然后都插入订单最终一个场次被卖两次。解决办法我在前面已经说过用条件更新UPDATE court_schedule SET status1 WHERE id? AND status0判断影响行数即可。但如果你的场次表没有status字段只有一张订单表那就要给订单表增加唯一索引比如(court_id, booking_date, start_time, end_time)靠数据库兜底防重。排查超卖问题时先打开MySQL慢日志或通用日志看两条更新语句的执行顺序而不是一开始就引入Redis锁或者分布式锁。对本科毕设来说数据库原子操作已经足够。5.3 真机调试时用Charles抓包小程序请求当小程序在真机上表现异常而开发者工具里一切正常时抓包是最直接的排查手段。我常用的流程是电脑和手机连同一个WiFiCharles开启SSL Proxying并安装手机端证书手机WiFi代理指向电脑IP和8888端口然后打开小程序在Charles里按接口路径过滤就能看到请求头和响应体。不过提醒一下抓包看自己的后端接口没问题但微信内部的接口比如wx.login和支付会做证书校验不一定能正常解包这并不代表代码有问题。如果只是想调试自己的API开发者工具自带Network面板其实更直观Charles更适合排查“模拟器正常、真机不行”这类环境差异问题。5.4 拿到源码后如何安全地二次开发很多同学害怕源码改坏了其实掌握顺序就不慌。我总结的稳妥流程是先看数据库脚本搞懂表关系接着启动后端用Apifox或Postman把核心接口挨个调通然后启动小程序完整走一遍登录到支付流程最后选一个自己熟悉的小模块动手改。比如给场地增加“收藏”功能或者给订单增加“评价”功能这种增量开发风险低又有话可讲。最忌讳一上来就改登录逻辑。登录是整条链路的地基改坏了所有请求都会401。我最早帮人改毕设时直接加了“微信手机号一键登录”结果后端token处理没跟上全部接口报错排查了大半个下午才发现是token校验顺序的问题。从那以后我就坚持“先跑通、再改小、后写文档”的顺序稳得多。最后再说一点个人体会这个题目做了几年最深的感受是计算机毕业设计最难的不是某个技术点而是“不知道从哪下手”的茫然感。基于小程序的篮球场馆预订系统之所以值得推荐就是因为它把用户、场地、订单、支付、管理这一整条业务链完整地摆在你面前每一条线都能讲出设计思路也都能在演示时直观看到效果。如果你手里正好有一套源码加LW文档别急着大改先把它跑成一个能演示的完整系统再逐步叠加自己的想法。最后分享一个很土但有效的小技巧答辩前把“从进入小程序到成功入场”的完整流程在真机上连续跑三遍每跑一遍都记录下遇到的问题和对应解法。这些真实问题就是最好的答辩素材比任何华丽的功能描述都更能体现你的实际工作量。祝各位顺利拿下这个题目。
最近好几个学弟学妹来找我看毕业设计题目都指向同一个方向——基于小程序的篮球场馆预订系统。这个题目在计算机毕业设计里确实属于典型的“业务闭环完整、前后端都有、小程序端自带亮点”的选题网上能找到不少现成的源码工程配套的LW文档也就是设计说明文档/论文也基本形成了一套成熟模板。这篇文章不是单纯给你贴一段代码然后说“能跑就行”而是沿着“拿到源码 → 读懂设计 → 改造成自己的 → 写出文档 → 顺利答辩”这条完整路线把这个系统里真正重要的业务逻辑、数据库设计、踩坑点一次讲透。1. 项目整体设计与技术选型1.1 系统核心功能拆解一个合格的篮球场馆预订系统业务上至少要覆盖用户端小程序、后台管理系统、支付与退款流程、场地状态管理四大部分。用户端主要做这些事微信登录和手机号授权、浏览场馆列表、查看场地详情、选择日期时段、创建订单、微信支付、取消订单、查看我的订单以及入场核销。管理端则负责场馆管理、场地管理、批量生成场次、订单管理、退款审核、数据统计和用户管理。这些功能听起来常规但真正动手时你会发现一个“待支付、已支付、已入场、已取消、已退款”的状态流转加上并发抢场、超时释放、退款回调已经能把一个学生的代码能力考得明明白白。之所以推荐这个题目就是因为它把“资源预订”这一类业务的核心矛盾——“同一时间段场地不能被重复预订”——用最简单直观的形式呈现出来了非常适合作为计算机毕业设计的业务主线。1.2 为什么选小程序而不是H5或App作为毕业设计选题小程序端的优势非常明显。演示时评委直接拿微信扫码就能打开完全不需要安装APK开发成本也比原生App低很多一套wxml/wxss/javascript代码就能覆盖iOS和Android最关键的是微信生态里现成的登录、支付、订阅消息能力正好对应预订系统的完整闭环。如果做成H5网页虽然也能实现功能但演示时你得先准备域名、HTTPS证书而且评委还得打开浏览器输地址体验差很多。小程序虽然在真机预览时也需要域名但开发者工具里勾选“不校验合法域名”后本地开发阶段完全可以跑通不要求你一开始就买服务器和域名。这对绝大多数学生来说省下了真金白银也让前期开发的阻力小很多。1.3 技术栈与部署结构不同源码包的技术选型会有些差异但主流组合大致是这样的端常用技术小程序端微信小程序原生 / uni-app后台管理端Vue Element-UI / Layui jQuery后端服务Spring Boot / SSM / Node.js Express数据库MySQL 5.7 或 8.0接口风格RESTful JSON鉴权方式JWT 或微信 session_key拿到一个源码压缩包之后千万不要急着点启动。我通常按下面的顺序排查结构先看根目录有没有README或部署说明再找项目里的数据库SQL脚本接着看后端配置文件里的数据库连接和端口最后分别启动后端、管理端、小程序端。很多时候所谓的“跑不起来”不是代码问题而是配置文件里的数据库密码没改、字符集不对、端口被占用这些问题按顺序排查一遍就能解决。2. 数据库设计与核心业务逻辑2.1 核心数据表设计篮球场馆预订系统的数据库表通常有这样几张user 用户表openid、nickname、phone、avatar、create_timevenue 场馆表name、address、image、description、open_time、close_timecourt 场地表venue_id、name、type半场/全场、price_per_hourcourt_schedule 场次表court_id、date、start_time、end_time、status、pricebooking_order 订单表order_no、user_id、court_id、schedule_id、booking_date、start_time、end_time、amount、status、pay_time、refund_timerefund_record 退款记录表order_id、reason、status、operate_time有些简单教程会把场次信息直接塞进订单表只记录日期和时段然后靠SQL查重判断是否冲突。这个方案能跑通但扩展性很差因为篮球馆不同时段的价格很可能不同工作日晚上和周末价格不一样同一个场地在不同日期也可能临时调价。单独拆一张court_schedule表后台可以灵活配置每个时段的开放状态和价格这才符合真实场馆运营的逻辑。2.2 预订冲突处理与状态机预算冲突是整个系统的核心难点。用户在页面选好“2号场地周五20:00到21:00”点击提交时后端不能只查一次“该时段有没有订单”因为两个用户可能同时读到“没有订单”然后同时插入订单最后超卖。正确的做法有两种。第一种是“原子更新状态标记”直接对场次表做条件更新UPDATE court_schedule SET status 1 WHERE id #{scheduleId} AND status 0;如果更新影响的行数是1说明当前用户成功锁定了这个场次继续创建订单如果返回0说明场次已经被抢走直接提示“该时段已被预订”。这种写法实现简单对本科毕设来说已经完全够用。第二种是事务加行锁在MySQL里用SELECT ... FOR UPDATE锁住对应场次记录再判断状态并插入订单最后提交事务。这种方案控制粒度更细但代码复杂度高一些也容易出现死锁建议只在扩展功能时考虑。订单状态建议统一用int字段表示0待支付、1已支付、2已入场、3已取消、4已退款。要注意“已取消”和“已退款”的区别已取消是用户未支付或超时未支付系统自动关闭已退款是用户支付成功后又申请了退款钱原路退回。这两个状态如果混在一起后台统计营收时会出大问题。2.3 支付与退款流程设计微信支付接入对许多学生来说是最容易卡住的环节。很多网上下载的源码里用的是“模拟支付”也就是点击支付后直接调一个后端接口把订单状态改成已支付绕过了微信支付服务器。本地演示没问题但如果答辩老师当场要求扫码就可能会露馅。我的建议是如果时间允许尽量接微信小程序支付。流程是后端调用微信支付统一下单接口拿到支付参数小程序调wx.requestPayment拉起收银台支付结果通过回调通知后端更新订单状态。这个流程涉及到商户号、AppID、商户API密钥等配置申请周期较长所以如果实在来不及在LW文档里明确写清楚“当前使用模拟支付环境接口结构已按微信支付标准预留”答辩时诚实说明反而不会扣分。退款功能一般放在管理端管理员审核退款申请后后端调用微信支付退款接口成功后更新订单状态并写入退款记录。这里要注意退款金额不能大于订单实付金额退款原因不能为空微信支付接口证书要配置正确否则会报“证书校验失败”之类的问题。3. 小程序端实操要点3.1 登录、手机号授权与token处理小程序登录的标准流程是这样先用wx.login拿到code把code发给后端后端拿code向微信接口换取openid和session_key然后后端自己生成一份token返回给小程序。小程序收到token后存入storage后续所有业务请求都带上这个token请求头。服务端通过token识别用户身份不需要每次请求都去微信接口校验。手机号授权这一块现在新版小程序已经改成了button open-typegetPhoneNumber组件用户同意后后端通过code换手机号。很多旧源码还在用wx.getUserProfile拿昵称头像这部分逻辑很可能会失效所以拿到源码之后第一件事就是检查登录和用户信息获取这里是否还能跑通。如果只想快点完成毕设可以给用户表加上“模拟登录”按钮直接指定一个测试用户ID绕过微信登录的繁琐限制演示时再走一遍真实wx.login这样就比较稳妥。3.2 场地选择与时段日历组件小程序端的核心页面是场地预订页。通常的进法是场馆列表 → 点击场馆 → 进入场馆详情 → 选择日期和时段 → 确认订单。日期选择我习惯用横向滚动的七天日期条用scroll-view实现每个日期显示“周一 03-08”这样的格式点击后切换日期。时段网格则把一天按半小时或一小时切成多个时间段已预约的格子置灰可预约的格子高亮。这里有一个特别容易踩的坑日期计算千万别用字符串拼接。比如“2025-03-08”减一天不能直接解析字符串后减1跨月时会出问题。要么用时间戳计算要么用dayjs或moment这样的工具库统一处理。另一个坑是价格一定要以后端返回为准小程序端不要自己算总价否则后台改价之后前端页面价格和后端不一致会出现订单金额对不上的问题。3.3 订单创建与支付集成用户选好时段后点击“立即预约”小程序端不能直接提交订单先进确认订单页。确认页展示场馆、场地、日期、时间、金额用户补充联系手机号和入场人数后再点提交。提交时调用后端创建订单接口后端锁场次并生成待支付订单然后返回支付参数。到这里有一个顺序问题必须注意一定是先锁场次再创建订单最后支付。如果把支付放在锁场次之前就会导致用户支付成功却抢不到场地或者用户关闭支付页面后场次还被锁住形成死单。解决死单的常用办法是给订单表加created_at字段后端做定时任务把超过15分钟未支付的待支付订单主动关闭并释放对应场次。这个定时任务虽然不起眼但写进LW文档里非常加分因为它体现了“可用性设计”的思考。3.4 入场核销与订阅消息入场环节通常是在“我的订单”里展示一个二维码管理员在后台扫描或输入核销码确认入场。如果嫌二维码生成麻烦可以让订单号直接作为核销码后台输入订单号后四位即可核销简单有效。订阅消息也是个不错的亮点。用户支付成功后小程序通过wx.requestSubscribeMessage申请一次性订阅消息授权后端在开场前通过接口向用户发送一条提醒。虽然一次性订阅消息只能发一次但“支付成功申请订阅 → 开场前发送提醒”这个闭环正好合理。答辩时把这个功能讲清楚能在系统完整度上加分不少。4. 后台管理系统与LW文档写作4.1 管理端功能怎么划分管理后台是整个系统里相对容易被忽略的部分但它的工作量一点也不小。常见模块包括仪表盘、场馆管理、场地管理、场次管理、订单管理、用户管理和系统设置。仪表盘要展示今日订单数、营收、场地利用率等统计指标这些统计SQL其实不难写但很多源码里只是放了一些静态假数据。如果想把项目做得更扎实建议让统计接口从订单表实时聚合哪怕数据量不大效果也远好过写死数字。“批量生成场次”这个功能强烈建议保留并搞懂。管理员在后台设置“生成本周场次”系统自动为每个场地创建未来7天每个时段的court_schedule记录。这个功能不仅是运营的真实需求答辩时现场演示“一键排场”也会让老师觉得系统完整度高。4.2 管理端与小程序的接口设计接口设计最好采用RESTful风格路径清晰一点GET /api/venue/list 场馆列表GET /api/venue/{id} 场馆详情GET /api/court/schedule?courtIddate 查询某天场次POST /api/order/create 创建订单POST /api/order/pay 支付订单POST /api/order/cancel 取消订单GET /api/admin/order/list 管理端订单列表POST /api/admin/order/refund 退款审核管理端接口必须做角色鉴权不能裸奔。网上很多毕设源码的后台接口不校验身份任何人拿到接口路径都能调这在答辩时是明显的技术漏洞。用Spring Boot的话可以在JWT里增加role字段拦截器统一判断管理员角色实现成本很低但整体安全性和专业性会明显提升。4.3 LW文档快速成稿思路LW文档对很多同学来说是比代码更痛苦的东西。其实只要结构清晰写起来并不难。通常展开成这几章绪论项目背景、国内外研究现状、研究意义、论文结构需求分析功能性需求、非功能需求、用例图系统设计架构图、功能模块图、数据库ER图、接口设计系统实现每个功能模块的截图、核心代码片段、实现思路系统测试测试环境、功能测试用例、结论总结与展望。写作时有三个核心原则第一图表不能少ER图、用例图、时序图、部署图是支撑篇幅和“专业感”的关键第二文档内容必须和源码保持一致字段名、接口路径、业务流程都不能对不上否则答辩时老师随便一问就穿帮第三体验过程要写透用“用户从打开小程序到完成入场”的完整流程文字描述比空谈架构更能让人信服。5. 常见问题与排查技巧实录5.1 小程序请求后端失败页面空白这类问题十有八九出在域名和端口上。开发者工具里需要在“详情-本地设置”勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”。而后端地址不能写localhost尤其是真机调试时手机上的localhost指向手机自己根本不可能是你的电脑。这种情况要把baseURL改成电脑的局域网IP比如http://192.168.1.101:8080。我之前帮一个学弟排查他的后端接口在浏览器里访问完全正常小程序模拟器也能通唯独真机上一片空白。最后发现就是localhost惹的祸改成局域网IP后立刻就好了。如果后端部署在远程服务器上还要注意服务器防火墙端口是否开放云服务器的安全组规则也要允许对应端口入站。5.2 同一时段并发预订出现超卖这个问题容易出现在“先查询再插入”的写法里。两个请求同时查到场次状态为0然后都插入订单最终一个场次被卖两次。解决办法我在前面已经说过用条件更新UPDATE court_schedule SET status1 WHERE id? AND status0判断影响行数即可。但如果你的场次表没有status字段只有一张订单表那就要给订单表增加唯一索引比如(court_id, booking_date, start_time, end_time)靠数据库兜底防重。排查超卖问题时先打开MySQL慢日志或通用日志看两条更新语句的执行顺序而不是一开始就引入Redis锁或者分布式锁。对本科毕设来说数据库原子操作已经足够。5.3 真机调试时用Charles抓包小程序请求当小程序在真机上表现异常而开发者工具里一切正常时抓包是最直接的排查手段。我常用的流程是电脑和手机连同一个WiFiCharles开启SSL Proxying并安装手机端证书手机WiFi代理指向电脑IP和8888端口然后打开小程序在Charles里按接口路径过滤就能看到请求头和响应体。不过提醒一下抓包看自己的后端接口没问题但微信内部的接口比如wx.login和支付会做证书校验不一定能正常解包这并不代表代码有问题。如果只是想调试自己的API开发者工具自带Network面板其实更直观Charles更适合排查“模拟器正常、真机不行”这类环境差异问题。5.4 拿到源码后如何安全地二次开发很多同学害怕源码改坏了其实掌握顺序就不慌。我总结的稳妥流程是先看数据库脚本搞懂表关系接着启动后端用Apifox或Postman把核心接口挨个调通然后启动小程序完整走一遍登录到支付流程最后选一个自己熟悉的小模块动手改。比如给场地增加“收藏”功能或者给订单增加“评价”功能这种增量开发风险低又有话可讲。最忌讳一上来就改登录逻辑。登录是整条链路的地基改坏了所有请求都会401。我最早帮人改毕设时直接加了“微信手机号一键登录”结果后端token处理没跟上全部接口报错排查了大半个下午才发现是token校验顺序的问题。从那以后我就坚持“先跑通、再改小、后写文档”的顺序稳得多。最后再说一点个人体会这个题目做了几年最深的感受是计算机毕业设计最难的不是某个技术点而是“不知道从哪下手”的茫然感。基于小程序的篮球场馆预订系统之所以值得推荐就是因为它把用户、场地、订单、支付、管理这一整条业务链完整地摆在你面前每一条线都能讲出设计思路也都能在演示时直观看到效果。如果你手里正好有一套源码加LW文档别急着大改先把它跑成一个能演示的完整系统再逐步叠加自己的想法。最后分享一个很土但有效的小技巧答辩前把“从进入小程序到成功入场”的完整流程在真机上连续跑三遍每跑一遍都记录下遇到的问题和对应解法。这些真实问题就是最好的答辩素材比任何华丽的功能描述都更能体现你的实际工作量。祝各位顺利拿下这个题目。
