简介面向高校体育场管理场景的微信小程序毕业设计资源包含完整前后端源码、数据库文件、开题报告、演示视频与论文文档适合计算机相关专业学生进行课程设计或毕业答辩。系统基于微信开发者工具与ThinkPHP框架构建实现管理员扫码登录、学生学号注册、校外人员手机号注册、场地信息维护和预约申请等核心功能技术栈涉及Vue、JavaScript、CSS及ECharts图表。压缩包共968个文件含175个png界面素材、162个svg图形、128个JavaScript逻辑文件、125个Vue组件以及数据库SQL脚本、部署批处理和演示MP4整体约33.36MB目录结构清晰便于按源码、文档和视频分类检索。资源已有147人学习既能帮助理解前后端交互与小程序开发流程也可直接作为功能演示、论文撰写和答辩讲解的参考资料。文件类型覆盖界面、逻辑、样式与说明文档适合边看边练。1. 从扫码预约到场地排期这个微信小程序体育场系统到底拆出了什么高校体育场管理的痛点从来不在「有没有场地」而在「场地信息散在 Excel、预约靠人工登记、管理员一天要改八次状态」。这套基于微信小程序的高校体育场管理系统前端跑在小程序里后台用 ThinkPHP Vue iView 搭起来数据库落在 MySQL典型的小程序 管理后台双端结构。对要做毕业设计的人它是一个能直接跑起来演示的完整闭环对已经在做管理系统的人它最有价值的其实是「场地预约 状态变更」这条主链路怎么把前端、接口、数据三层的状态保持一致。整套东西包含小程序端源码、PHP 后台源码、数据库文件、开题报告、演示视频和论文。理论上是「拿到就能跑、跑完能改、改完能写进论文」的完整资源但实际跑起来有几个隐蔽的坑比如微信登录的 code 换 token 流程、场地时间段的并发冲突、以及 ThinkPHP 的伪静态配置。下面从整体架构开始拆再逐步落到代码和排错。适合准备做管理系统类毕设的学生也适合想快速搭一套预约系统的开发者参考。2. 系统架构与数据模型ThinkPHP MySQL 的预约链路怎么设计2.1 双端架构下权限模型是怎么拆的这套系统分成微信小程序端、PHP 后台管理端两个入口共用同一个 MySQL 数据库。小程序端面向两类人高校学生通过学号注册登录校外人员用手机号注册登录后台管理端只有管理员能进负责场地信息维护、预约审核、统计报表。管理员登录走的是二维码扫码登录这个「扫二维码登录」很容易被误读成小程序扫一扫实际拆开看是后台管理端的 PC 页面生成一个带参数的二维码管理员用已绑定身份的微信扫码后通过微信网页授权拿到 openid 完成登录。这和 C 端小程序里学生用微信登录走的是两套不同的微信 API后台扫码用的是OAuth2.0网页授权小程序端用的是wx.login获取 code 再换 token。权限控制的粒度上学生、校外人员、管理员三个角色的接口权限完全不同。学生只能操作自己的预约记录校外人员不能查看校内学生的学号信息管理员只能操作场地和审核而不能替学生提交预约。这种 RBAC 模型在这类系统中属于标配但实现时很多人会把角色判断写死在 Controller 里后续要扩展角色就需要到处改代码。2.2 MySQL 核心表结构与字段设计预约系统的核心表大致有这六张用户表、场地表、场地类型表、预约表、时段表、操作日志表。下面是关键表的字段设计按实际开发中最常见的方式来定义。用户表与场地表用户表user的关键字段字段类型说明idint(11) PK用户IDopenidvarchar(64)微信openid用于小程序登录student_novarchar(20)学号学生注册时必填phonevarchar(11)手机号校外人员注册时必填roletinyint(1)1学生 2校外人员 3管理员reg_timedatetime注册时间场地表venue的字段重点是状态和排期信息的冗余设计字段类型说明idint(11) PK场地IDnamevarchar(50)场地名称如「篮球场1号」type_idint(11)关联场地类型表pricedecimal(10,2)每小时费用校外人员可能不同价statustinyint(1)1可用 0停用open_timevarchar(20)开放时间段如 08:00-22:00这里有个设计细节值得注意场地状态status表示的是「管理端是否允许预约」而某天某个时段是否已经被约不应该存在场地表里应该由预约表实时计算。很多人一开始会把「已约满」直接写进场地表结果同一块场地在不同日期的占用状态就互相覆盖了。正确做法是场地表只存基础信息和启停状态可预约与否通过预约表实时查询。预约表与时段设计预约表reservation是整套系统数据一致性的关键所在CREATE TABLE reservation ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id int(11) NOT NULL COMMENT 预约人ID, venue_id int(11) NOT NULL COMMENT 场地ID, reserve_date date NOT NULL COMMENT 预约日期, time_slot varchar(20) NOT NULL COMMENT 时间段如 18:00-20:00, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待审核 1已通过 2已拒绝 3已取消, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_venue_date (venue_id,reserve_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;time_slot字段用字符串直接存时间段比如18:00-20:00。这种设计够用但并不优雅更好的做法是单独建一张time_slot字典表把一天切成固定时段预约表存slot_id。好处有两个一是前端选择器可以直接渲染字典表不用硬编码二是统计某个时段的使用率时用slot_id做 GROUP BY 比解析字符串高效得多。不过考虑到毕设体量字符串设计也能接受只是查询18:00-20:00和20:00-22:00是否重叠时需要额外写判断逻辑。2.3 为什么选 ThinkPHP PHP 写后台后台用 ThinkPHP 框架 PHP 语言实现这一点经常被说「不够现代」但在毕设场景下反而是合理的。PHP 的语法混合了 C、Java、Perl 的风格能嵌入 HTML编辑简单、部署成本低对初学者友好。ThinkPHP 是国内使用率很高的 PHP 框架路由、ORM、模板引擎、验证器这些都有现成实现写一个管理后台比从零手写快很多。MySQL 的选择没什么悬念关系型数据库、数据存在不同的表中、灵活性强、速度快社区版免费且开源中小型系统的标配。和 PostgreSQL 相比MySQL 在 Windows 环境和 PHP 的搭配资料更多出问题容易搜到解决方案。对毕设来说「可复现性」比「技术先进性」更重要选 MySQL 几乎是必然。3. 预约流程的实现从扫码登录、场地查询到提交预约与审核3.1 小程序端登录与 token 换取流程小程序端登录是整套系统的入口接口设计必须搞清楚。学生打开小程序后前端调用wx.login()获取临时 code然后传给后端接口换取登录态。这里最常踩的坑是把 code 当成 token 用或者在数据库里存 code。code 有效期只有五分钟而且只能用一次换到 openid 之后就没用了必须由后端把 openid 映射到自定义 token比如 JWT 或 session_id返回给前端。后端换取登录态的代码示例如下public function login() { $code input(post.code); $appid config(wechat.appid); $secret config(wechat.secret); // 1. 用 code 换取 openid 和 session_key $url https://api.weixin.qq.com/sns/jscode2session?appid{$appid}secret{$secret}js_code{$code}grant_typeauthorization_code; $result file_get_contents($url); $data json_decode($result, true); if (isset($data[errcode])) { return json([code 1, msg 登录失败 . $data[errmsg]]); } $openid $data[openid]; // 2. 查数据库没有则按注册流程处理 $user Db::name(user)-where(openid, $openid)-find(); if (!$user) { return json([code 2, msg 未注册, openid $openid]); } // 3. 生成自定义 token 并返回 $token md5($openid . time() . rand(1000, 9999)); Db::name(user)-where(id, $user[id])-update([token $token]); return json([code 0, token $token, user_info $user]); }这段逻辑里有几个关键点第一步的jscode2session接口是微信官方的code换openid是必须的中间步骤第二步判断用户是否已注册未注册的前端要跳转注册页补充学号或手机号第三步自定义 token 是为了后续接口鉴权避免每次请求都拿 openid 去查库。后续所有需要登录态的接口前端在请求头里带Authorization: Bearer token后端用 ThinkPHP 的中间件统一校验。这里用file_get_contents是简化写法实际生产建议改用 Guzzle 或 curl方便处理超时和错误码。3.2 场地查询接口与前端渲染场地查询是预约的前置步骤。小程序端进入预约页面先加载可用场地列表。接口要支持按场地类型筛选和按日期查询因为同一天不同时段某块场地可能已经被预约。后端查询接口设计如下public function venueList() { $type_id input(get.type_id, 0); $date input(get.date, date(Y-m-d)); $where [status 1]; if ($type_id 0) { $where[type_id] $type_id; } $venues Db::name(venue)-where($where)-select()-toArray(); foreach ($venues as $venue) { // 查询该场地在指定日期已预约且状态为已通过的时间段 $booked Db::name(reservation) -where(venue_id, $venue[id]) -where(reserve_date, $date) -where(status, 1) -column(time_slot); $venue[booked_slots] $booked; } return json([code 0, data $venues]); }注意status条件只有「已通过」的预约才占用场地待审核的不算。但这会引入一个问题——如果一个人提交了待审核预约另一个人同时看到该时段可约也提交了审核时就会出现两个都通过、场地冲突的局面。解决方式有两个简单做法是审核时检查预约表里同场地同时段是否已有状态为 1已通过的记录有则拒绝严格做法是在预约表加唯一索引或在提交预约时做事务锁后面 4.2 节详细说。前端小程序端的渲染逻辑是在onLoad里请求场地列表用wx.request请求上面的接口拿到booked_slots数组后时段选择器把已预约的时段置灰。Page({ data: { venueList: [], selectedDate: , selectedVenue: null, slotList: [] }, loadVenues() { const that this; wx.request({ url: https://yourdomain.com/api/venue/list, data: { type_id: 0, date: this.data.selectedDate }, success(res) { if (res.data.code 0) { that.setData({ venueList: res.data.data }); } } }); }, selectVenue(e) { const id e.currentTarget.dataset.id; const venue this.data.venueList.find(v v.id id); this.setData({ selectedVenue: venue }); this.buildSlotList(venue.booked_slots); }, buildSlotList(bookedSlots) { const allSlots [08:00-10:00, 10:00-12:00, 14:00-16:00, 16:00-18:00, 18:00-20:00]; const slotList allSlots.map(slot ({ time: slot, disabled: bookedSlots.includes(slot) })); this.setData({ slotList }); } });这里时段列表直接硬编码是毕设常见做法如果要做得更完整应该从后端/api/slot/list拉取时段字典。disabled字段在前端渲染时控制按钮是否可点击但这种控制只是用户体验层面的后端提交时仍然要校验。3.3 提交预约的事务处理和并发控制提交预约是这个系统最核心的接口必须处理并发冲突。两名学生在同一秒提交同一块场地同一时段的预约如果后端只做简单的INSERT两条记录都能写进去后续审核就会撞车。常见做法是先查再插但查和插之间存在时间差并发请求下依然会重复插入。这里推荐用数据库事务 SELECT ... FOR UPDATE锁定行记录。ThinkPHP 5 中的事务写法public function submitReservation() { $user_id $this-getUserId(); // 从 token 解析 $venue_id input(post.venue_id); $reserve_date input(post.reserve_date); $time_slot input(post.time_slot); Db::startTrans(); try { // 锁定该场地记录防止并发重复预约 $venue Db::name(venue)-where(id, $venue_id)-lock(true)-find(); if (!$venue || $venue[status] ! 1) { Db::rollback(); return json([code 1, msg 场地不可预约]); } // 检查该时段是否已被占用 $exists Db::name(reservation) -where(venue_id, $venue_id) -where(reserve_date, $reserve_date) -where(time_slot, $time_slot) -where(status, 1) -find(); if ($exists) { Db::rollback(); return json([code 1, msg 该时段已被预约]); } // 生成订单号并插入预约记录 $order_no date(YmdHis) . rand(1000, 9999); Db::name(reservation)-insert([ order_no $order_no, user_id $user_id, venue_id $venue_id, reserve_date $reserve_date, time_slot $time_slot, status 0, // 待审核 create_time date(Y-m-d H:i:s) ]); Db::commit(); return json([code 0, msg 提交成功等待审核]); } catch (\Exception $e) { Db::rollback(); return json([code 1, msg 系统繁忙请重试]); } }lock(true)在 ThinkPHP 中会生成FOR UPDATE语句锁住venue表中对应记录的行锁直到事务提交或回滚才释放。两个并发请求同时进来第二个会阻塞在lock这一行等第一个事务结束后再执行检查此时就能查到已插入的记录返回「已被预约」。依赖 InnoDB 的行锁机制MyISAM 引擎不支持FOR UPDATE这也是为什么建表时必须指定ENGINEInnoDB。3.4 后台审核与场地维护操作管理后台的场地维护和预约审核分布在不同的菜单模块路由结构大致如下模块路由功能场地管理/admin/venue/index列表 查询添加场地/admin/venue/add新增场地编辑场地/admin/venue/edit修改场地信息预约审核/admin/reservation/review审核通过/拒绝预约列表/admin/reservation/index所有预约记录数据统计/admin/statistics/index按场地、按日的预约量审核接口用 ThinkPHP 验证器校验状态值的合法性不能直接接受前端传status 1就放行。严谨的做法是先查预约记录当前状态只有「待审核」状态才能被更新为「已通过」或「已拒绝」否则返回「该记录已被处理」。审核通过时要再次校验场地时段是否已被其他已通过的预约占用形成双保险。管理员修改场地信息时如果场地已被预约改价格会影响已通过订单实际业务中可以先拒绝或提示管理员「该场地存在未完成的预约」。4. 部署与可视化从本地跑通到数据图表展示4.1 Windows 本地环境搭建与常见启动问题这套项目压缩包里带了1-install.bat和2-run.bat属于一键部署脚本但别指望双击就能跑前提取决于你本地有没有装好 PHP MySQL 微信开发者工具。常见的本地环境组合是 phpStudy 或 WAMP把项目根目录放到WWW下导入数据库文件修改application/database.php里的数据库连接配置。# 1-install.bat 内部大致做的事情 cd /d %~dp0 composer install php think migrate:run如果composer install执行失败一般是因为 PHP 未加入系统环境变量或者 composer 镜像源访问慢。国内网络环境建议先切 composer 镜像源再装依赖composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/2-run.bat的作用通常是启动 PHP 内置服务器或打开本地站点php think run -p 8080访问http://localhost:8080即可看到管理后台入口。微信小程序端的app.js中request请求的 baseURL 也要改成局域网 IP而不是localhost因为微信开发者工具中真机调试时手机访问localhost指向的是手机本身。4.2 管理员登录二维码实现与注意点后台管理员扫码登录的实现路径是PC 后台生成一个携带随机login_code的二维码前端轮询登录状态接口管理员用微信扫码后跳转到授权页面拿到code后调后端接口绑定login_code和 openidPC 端轮询接口检测到login_code状态变为已绑定就放行登录。生成二维码的核心 PHP 代码public function getLoginQrcode() { $login_code md5(uniqid() . rand(1000, 9999)); // 存入缓存或数据库有效期 2 分钟 cache(login_code_ . $login_code, 0, 120); // 返回二维码内容实际内容是一个带参数的 URL $qr_content url(wechat/scanLogin, [code $login_code], true, true); return json([code 0, qr_content $qr_content, login_code $login_code]); }这里cache()用的是 ThinkPHP 的缓存机制默认文件缓存即可。轮询接口负责把login_code变为已绑定状态的数据返回给 PC 端同时生成后台登录 session。容易出错的地方是二维码 URL 的域名本地调试时微信公众平台后台的回调域名不能配置localhost需要用内网穿透工具或者把校验文件放到服务器上开发阶段用测试号就能跳过这一步。4.3 预约数据可视化ECharts 图表统计项目技术栈里有 ECharts这部分一般放在后台首页展示场地预约热度、每日预约量趋势、场地使用率排行。后台接口返回统计数据的 JSON前端用 ECharts 渲染。常见统计口径有两个按日期统计每天的预约订单数按场地统计各场地的累计预约时长或次数。public function statistics() { // 近 7 天预约趋势 $start date(Y-m-d, strtotime(-7 days)); $list Db::name(reservation) -field(DATE_FORMAT(reserve_date, %m-%d) as date, COUNT(*) as total) -where(reserve_date, , $start) -where(status, 1) -group(reserve_date) -select() -toArray(); $trend []; for ($i 6; $i 0; $i--) { $d date(m-d, strtotime(-{$i} days)); $found array_filter($list, function ($v) use ($d) { return $v[date] $d; }); $trend[] [date $d, total $found ? array_values($found)[0][total] : 0]; } // 各场地使用率排行按预约次数 $venueRank Db::name(reservation) -alias(r) -join(venue v, r.venue_id v.id) -field(v.name, COUNT(*) as total) -where(r.status, 1) -group(r.venue_id) -order(total desc) -select() -toArray(); return json([code 0, trend $trend, venue_rank $venueRank]); }统计接口里有几个值得注意的细节DATE_FORMAT的格式化要在group和where中保持一致不然日期分组会产生错位近七天趋势的补零逻辑是把数据库查出的稀疏数据补齐为连续日期序列才能直接喂给 ECharts 的折线图使用率排行按预约次数统计是「次数口径」更精确的应该是按小时数统计即SUM(TIMESTAMPDIFF(...))看论文需要哪种口径就选哪种。前端 ECharts 渲染时要注意在管理后台的 Vue 组件中正确初始化图表实例import * as echarts from echarts; mounted() { this.initTrendChart(); }, methods: { initTrendChart() { const chart echarts.init(document.getElementById(trendChart)); // request 获取统计数据后 setOption chart.setOption({ tooltip: { trigger: axis }, xAxis: { type: category, data: this.trendDates }, yAxis: { type: value }, series: [{ type: line, data: this.trendCounts, areaStyle: {} }] }); } }mounted生命周期里初始化图表是正确位置不要在created里操作 DOM因为此时节点还没渲染出来。areaStyle让折线图带上渐变填充色视觉上更适合管理系统首页。Tab 页切换时注意图表宽度的自适应问题通常用window.onresize调用chart.resize()。5. 订单号生成策略与接口安全防护的进阶处理5.1 订单号的两种生成方式对比预约表里的order_no字段虽然只是业务编号但生成方式值得讲究。最省事的写法是上面提交预约接口里的date(YmdHis) . rand(1000, 9999)能保证基本唯一但在同一秒内并发提交时仍有碰撞可能。更稳妥的方式是用uniqid()配合md5散列或者用 ThinkPHP 自带的Db::name(reservation)-max(id) 1拼接日期前缀。业界常见的订单号规则是「日期 随机数 用户ID尾号」例如20240520183012888001。这种格式便于按日期范围模糊搜索也能从订单号反推用户维度做散列。这里给一个实际可用的生成函数function generateOrderNo($userId) { $datePart date(YmdHis); $randPart str_pad(mt_rand(0, 999999), 6, 0, STR_PAD_LEFT); $userPart str_pad($userId % 1000, 3, 0, STR_PAD_LEFT); return $datePart . $randPart . $userPart; }这个函数里str_pad保证了随机部分固定六位不会因为随机数小导致订单号长度不一致userId % 1000取用户 ID 后三位用于分库分表时的散列依据。毕设项目不涉及分库分表但生成逻辑保持规范总没坏处。5.2 接口防刷与身份校验预约系统面向全校师生接口安全性不能完全不管。最基础的三道防线是登录 token 校验、请求频率限制、关键操作二次验证。Token 校验用 ThinkPHP 中间件统一处理在application/http/middleware.php中注册class AuthMiddleware { public function handle($request, \Closure $next) { $token $request-header(authorization); $token str_replace(Bearer , , $token); $user Db::name(user)-where(token, $token)-find(); if (!$user) { return json([code 401, msg 请先登录]); } $request-user $user; return $next($request); } }请求频率限制的常见做法是记录每个 token 的接口调用时间戳一分钟内超过阈值直接拒绝。ThinkPHP 里可以用缓存实现$key rate_limit_ . $token; $count cache($key) ?: 0; if ($count 30) { return json([code 1, msg 请求过于频繁]); } cache($key, $count 1, 60);这种计数器模式的限流不是精确限流临界点可能放过少量请求但对毕设和校园内部系统够用。如果要做到更严格的滑动窗口或令牌桶就得引入 Redis 了项目复杂度会明显上升。5.3 部署上线时的 PHP 配置与常见坑本地跑通和真正部署到服务器是两回事。服务器上跑 ThinkPHP 项目php.ini的这几项配置直接影响系统是否正常file_uploads On upload_max_filesize 20M post_max_size 20M max_execution_time 60post_max_size必须大于upload_max_filesize否则上传场地图片时会报错。另外 ThinkPHP 5 需要开启伪静态Nginx 配置如下location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } }Apache 环境则是在项目根目录放.htaccess文件。很多人在本地用 phpStudy 的 Apache 跑没问题一到 Nginx 服务器上就 404基本都是伪静态没配。数据库连接配置里host不要写localhost在云服务器上写成127.0.0.1更可靠因为 PHP 在某些环境下解析localhost会优先走 IPv6 导致连接超时。5.4 演示视频录制与论文结构对应资源里带了演示视频和论文这两部分不是孤立的。录制演示视频时建议按照论文中的功能模块顺序操作先演示前台小程序注册登录再演示场地查询预约最后切到后台展示审核流程和图表统计这样评委看视频时能对应上论文结构。论文的核心章节安排一般是绪论、需求分析、系统设计、系统实现、系统测试其中「系统设计」对应数据库表结构设计「系统实现」对应每个功能模块的代码截图和页面截图。技术选型部分重点写明为什么用 PHP MySQL把 ThinkPHP 的优点和 MySQL 的适用场景写上就是论文里完整的可行性分析。本文还有配套的精品资源点击获取
基于微信小程序的高校体育场预约管理系统技术解析
简介面向高校体育场管理场景的微信小程序毕业设计资源包含完整前后端源码、数据库文件、开题报告、演示视频与论文文档适合计算机相关专业学生进行课程设计或毕业答辩。系统基于微信开发者工具与ThinkPHP框架构建实现管理员扫码登录、学生学号注册、校外人员手机号注册、场地信息维护和预约申请等核心功能技术栈涉及Vue、JavaScript、CSS及ECharts图表。压缩包共968个文件含175个png界面素材、162个svg图形、128个JavaScript逻辑文件、125个Vue组件以及数据库SQL脚本、部署批处理和演示MP4整体约33.36MB目录结构清晰便于按源码、文档和视频分类检索。资源已有147人学习既能帮助理解前后端交互与小程序开发流程也可直接作为功能演示、论文撰写和答辩讲解的参考资料。文件类型覆盖界面、逻辑、样式与说明文档适合边看边练。1. 从扫码预约到场地排期这个微信小程序体育场系统到底拆出了什么高校体育场管理的痛点从来不在「有没有场地」而在「场地信息散在 Excel、预约靠人工登记、管理员一天要改八次状态」。这套基于微信小程序的高校体育场管理系统前端跑在小程序里后台用 ThinkPHP Vue iView 搭起来数据库落在 MySQL典型的小程序 管理后台双端结构。对要做毕业设计的人它是一个能直接跑起来演示的完整闭环对已经在做管理系统的人它最有价值的其实是「场地预约 状态变更」这条主链路怎么把前端、接口、数据三层的状态保持一致。整套东西包含小程序端源码、PHP 后台源码、数据库文件、开题报告、演示视频和论文。理论上是「拿到就能跑、跑完能改、改完能写进论文」的完整资源但实际跑起来有几个隐蔽的坑比如微信登录的 code 换 token 流程、场地时间段的并发冲突、以及 ThinkPHP 的伪静态配置。下面从整体架构开始拆再逐步落到代码和排错。适合准备做管理系统类毕设的学生也适合想快速搭一套预约系统的开发者参考。2. 系统架构与数据模型ThinkPHP MySQL 的预约链路怎么设计2.1 双端架构下权限模型是怎么拆的这套系统分成微信小程序端、PHP 后台管理端两个入口共用同一个 MySQL 数据库。小程序端面向两类人高校学生通过学号注册登录校外人员用手机号注册登录后台管理端只有管理员能进负责场地信息维护、预约审核、统计报表。管理员登录走的是二维码扫码登录这个「扫二维码登录」很容易被误读成小程序扫一扫实际拆开看是后台管理端的 PC 页面生成一个带参数的二维码管理员用已绑定身份的微信扫码后通过微信网页授权拿到 openid 完成登录。这和 C 端小程序里学生用微信登录走的是两套不同的微信 API后台扫码用的是OAuth2.0网页授权小程序端用的是wx.login获取 code 再换 token。权限控制的粒度上学生、校外人员、管理员三个角色的接口权限完全不同。学生只能操作自己的预约记录校外人员不能查看校内学生的学号信息管理员只能操作场地和审核而不能替学生提交预约。这种 RBAC 模型在这类系统中属于标配但实现时很多人会把角色判断写死在 Controller 里后续要扩展角色就需要到处改代码。2.2 MySQL 核心表结构与字段设计预约系统的核心表大致有这六张用户表、场地表、场地类型表、预约表、时段表、操作日志表。下面是关键表的字段设计按实际开发中最常见的方式来定义。用户表与场地表用户表user的关键字段字段类型说明idint(11) PK用户IDopenidvarchar(64)微信openid用于小程序登录student_novarchar(20)学号学生注册时必填phonevarchar(11)手机号校外人员注册时必填roletinyint(1)1学生 2校外人员 3管理员reg_timedatetime注册时间场地表venue的字段重点是状态和排期信息的冗余设计字段类型说明idint(11) PK场地IDnamevarchar(50)场地名称如「篮球场1号」type_idint(11)关联场地类型表pricedecimal(10,2)每小时费用校外人员可能不同价statustinyint(1)1可用 0停用open_timevarchar(20)开放时间段如 08:00-22:00这里有个设计细节值得注意场地状态status表示的是「管理端是否允许预约」而某天某个时段是否已经被约不应该存在场地表里应该由预约表实时计算。很多人一开始会把「已约满」直接写进场地表结果同一块场地在不同日期的占用状态就互相覆盖了。正确做法是场地表只存基础信息和启停状态可预约与否通过预约表实时查询。预约表与时段设计预约表reservation是整套系统数据一致性的关键所在CREATE TABLE reservation ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id int(11) NOT NULL COMMENT 预约人ID, venue_id int(11) NOT NULL COMMENT 场地ID, reserve_date date NOT NULL COMMENT 预约日期, time_slot varchar(20) NOT NULL COMMENT 时间段如 18:00-20:00, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待审核 1已通过 2已拒绝 3已取消, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_venue_date (venue_id,reserve_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;time_slot字段用字符串直接存时间段比如18:00-20:00。这种设计够用但并不优雅更好的做法是单独建一张time_slot字典表把一天切成固定时段预约表存slot_id。好处有两个一是前端选择器可以直接渲染字典表不用硬编码二是统计某个时段的使用率时用slot_id做 GROUP BY 比解析字符串高效得多。不过考虑到毕设体量字符串设计也能接受只是查询18:00-20:00和20:00-22:00是否重叠时需要额外写判断逻辑。2.3 为什么选 ThinkPHP PHP 写后台后台用 ThinkPHP 框架 PHP 语言实现这一点经常被说「不够现代」但在毕设场景下反而是合理的。PHP 的语法混合了 C、Java、Perl 的风格能嵌入 HTML编辑简单、部署成本低对初学者友好。ThinkPHP 是国内使用率很高的 PHP 框架路由、ORM、模板引擎、验证器这些都有现成实现写一个管理后台比从零手写快很多。MySQL 的选择没什么悬念关系型数据库、数据存在不同的表中、灵活性强、速度快社区版免费且开源中小型系统的标配。和 PostgreSQL 相比MySQL 在 Windows 环境和 PHP 的搭配资料更多出问题容易搜到解决方案。对毕设来说「可复现性」比「技术先进性」更重要选 MySQL 几乎是必然。3. 预约流程的实现从扫码登录、场地查询到提交预约与审核3.1 小程序端登录与 token 换取流程小程序端登录是整套系统的入口接口设计必须搞清楚。学生打开小程序后前端调用wx.login()获取临时 code然后传给后端接口换取登录态。这里最常踩的坑是把 code 当成 token 用或者在数据库里存 code。code 有效期只有五分钟而且只能用一次换到 openid 之后就没用了必须由后端把 openid 映射到自定义 token比如 JWT 或 session_id返回给前端。后端换取登录态的代码示例如下public function login() { $code input(post.code); $appid config(wechat.appid); $secret config(wechat.secret); // 1. 用 code 换取 openid 和 session_key $url https://api.weixin.qq.com/sns/jscode2session?appid{$appid}secret{$secret}js_code{$code}grant_typeauthorization_code; $result file_get_contents($url); $data json_decode($result, true); if (isset($data[errcode])) { return json([code 1, msg 登录失败 . $data[errmsg]]); } $openid $data[openid]; // 2. 查数据库没有则按注册流程处理 $user Db::name(user)-where(openid, $openid)-find(); if (!$user) { return json([code 2, msg 未注册, openid $openid]); } // 3. 生成自定义 token 并返回 $token md5($openid . time() . rand(1000, 9999)); Db::name(user)-where(id, $user[id])-update([token $token]); return json([code 0, token $token, user_info $user]); }这段逻辑里有几个关键点第一步的jscode2session接口是微信官方的code换openid是必须的中间步骤第二步判断用户是否已注册未注册的前端要跳转注册页补充学号或手机号第三步自定义 token 是为了后续接口鉴权避免每次请求都拿 openid 去查库。后续所有需要登录态的接口前端在请求头里带Authorization: Bearer token后端用 ThinkPHP 的中间件统一校验。这里用file_get_contents是简化写法实际生产建议改用 Guzzle 或 curl方便处理超时和错误码。3.2 场地查询接口与前端渲染场地查询是预约的前置步骤。小程序端进入预约页面先加载可用场地列表。接口要支持按场地类型筛选和按日期查询因为同一天不同时段某块场地可能已经被预约。后端查询接口设计如下public function venueList() { $type_id input(get.type_id, 0); $date input(get.date, date(Y-m-d)); $where [status 1]; if ($type_id 0) { $where[type_id] $type_id; } $venues Db::name(venue)-where($where)-select()-toArray(); foreach ($venues as $venue) { // 查询该场地在指定日期已预约且状态为已通过的时间段 $booked Db::name(reservation) -where(venue_id, $venue[id]) -where(reserve_date, $date) -where(status, 1) -column(time_slot); $venue[booked_slots] $booked; } return json([code 0, data $venues]); }注意status条件只有「已通过」的预约才占用场地待审核的不算。但这会引入一个问题——如果一个人提交了待审核预约另一个人同时看到该时段可约也提交了审核时就会出现两个都通过、场地冲突的局面。解决方式有两个简单做法是审核时检查预约表里同场地同时段是否已有状态为 1已通过的记录有则拒绝严格做法是在预约表加唯一索引或在提交预约时做事务锁后面 4.2 节详细说。前端小程序端的渲染逻辑是在onLoad里请求场地列表用wx.request请求上面的接口拿到booked_slots数组后时段选择器把已预约的时段置灰。Page({ data: { venueList: [], selectedDate: , selectedVenue: null, slotList: [] }, loadVenues() { const that this; wx.request({ url: https://yourdomain.com/api/venue/list, data: { type_id: 0, date: this.data.selectedDate }, success(res) { if (res.data.code 0) { that.setData({ venueList: res.data.data }); } } }); }, selectVenue(e) { const id e.currentTarget.dataset.id; const venue this.data.venueList.find(v v.id id); this.setData({ selectedVenue: venue }); this.buildSlotList(venue.booked_slots); }, buildSlotList(bookedSlots) { const allSlots [08:00-10:00, 10:00-12:00, 14:00-16:00, 16:00-18:00, 18:00-20:00]; const slotList allSlots.map(slot ({ time: slot, disabled: bookedSlots.includes(slot) })); this.setData({ slotList }); } });这里时段列表直接硬编码是毕设常见做法如果要做得更完整应该从后端/api/slot/list拉取时段字典。disabled字段在前端渲染时控制按钮是否可点击但这种控制只是用户体验层面的后端提交时仍然要校验。3.3 提交预约的事务处理和并发控制提交预约是这个系统最核心的接口必须处理并发冲突。两名学生在同一秒提交同一块场地同一时段的预约如果后端只做简单的INSERT两条记录都能写进去后续审核就会撞车。常见做法是先查再插但查和插之间存在时间差并发请求下依然会重复插入。这里推荐用数据库事务 SELECT ... FOR UPDATE锁定行记录。ThinkPHP 5 中的事务写法public function submitReservation() { $user_id $this-getUserId(); // 从 token 解析 $venue_id input(post.venue_id); $reserve_date input(post.reserve_date); $time_slot input(post.time_slot); Db::startTrans(); try { // 锁定该场地记录防止并发重复预约 $venue Db::name(venue)-where(id, $venue_id)-lock(true)-find(); if (!$venue || $venue[status] ! 1) { Db::rollback(); return json([code 1, msg 场地不可预约]); } // 检查该时段是否已被占用 $exists Db::name(reservation) -where(venue_id, $venue_id) -where(reserve_date, $reserve_date) -where(time_slot, $time_slot) -where(status, 1) -find(); if ($exists) { Db::rollback(); return json([code 1, msg 该时段已被预约]); } // 生成订单号并插入预约记录 $order_no date(YmdHis) . rand(1000, 9999); Db::name(reservation)-insert([ order_no $order_no, user_id $user_id, venue_id $venue_id, reserve_date $reserve_date, time_slot $time_slot, status 0, // 待审核 create_time date(Y-m-d H:i:s) ]); Db::commit(); return json([code 0, msg 提交成功等待审核]); } catch (\Exception $e) { Db::rollback(); return json([code 1, msg 系统繁忙请重试]); } }lock(true)在 ThinkPHP 中会生成FOR UPDATE语句锁住venue表中对应记录的行锁直到事务提交或回滚才释放。两个并发请求同时进来第二个会阻塞在lock这一行等第一个事务结束后再执行检查此时就能查到已插入的记录返回「已被预约」。依赖 InnoDB 的行锁机制MyISAM 引擎不支持FOR UPDATE这也是为什么建表时必须指定ENGINEInnoDB。3.4 后台审核与场地维护操作管理后台的场地维护和预约审核分布在不同的菜单模块路由结构大致如下模块路由功能场地管理/admin/venue/index列表 查询添加场地/admin/venue/add新增场地编辑场地/admin/venue/edit修改场地信息预约审核/admin/reservation/review审核通过/拒绝预约列表/admin/reservation/index所有预约记录数据统计/admin/statistics/index按场地、按日的预约量审核接口用 ThinkPHP 验证器校验状态值的合法性不能直接接受前端传status 1就放行。严谨的做法是先查预约记录当前状态只有「待审核」状态才能被更新为「已通过」或「已拒绝」否则返回「该记录已被处理」。审核通过时要再次校验场地时段是否已被其他已通过的预约占用形成双保险。管理员修改场地信息时如果场地已被预约改价格会影响已通过订单实际业务中可以先拒绝或提示管理员「该场地存在未完成的预约」。4. 部署与可视化从本地跑通到数据图表展示4.1 Windows 本地环境搭建与常见启动问题这套项目压缩包里带了1-install.bat和2-run.bat属于一键部署脚本但别指望双击就能跑前提取决于你本地有没有装好 PHP MySQL 微信开发者工具。常见的本地环境组合是 phpStudy 或 WAMP把项目根目录放到WWW下导入数据库文件修改application/database.php里的数据库连接配置。# 1-install.bat 内部大致做的事情 cd /d %~dp0 composer install php think migrate:run如果composer install执行失败一般是因为 PHP 未加入系统环境变量或者 composer 镜像源访问慢。国内网络环境建议先切 composer 镜像源再装依赖composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/2-run.bat的作用通常是启动 PHP 内置服务器或打开本地站点php think run -p 8080访问http://localhost:8080即可看到管理后台入口。微信小程序端的app.js中request请求的 baseURL 也要改成局域网 IP而不是localhost因为微信开发者工具中真机调试时手机访问localhost指向的是手机本身。4.2 管理员登录二维码实现与注意点后台管理员扫码登录的实现路径是PC 后台生成一个携带随机login_code的二维码前端轮询登录状态接口管理员用微信扫码后跳转到授权页面拿到code后调后端接口绑定login_code和 openidPC 端轮询接口检测到login_code状态变为已绑定就放行登录。生成二维码的核心 PHP 代码public function getLoginQrcode() { $login_code md5(uniqid() . rand(1000, 9999)); // 存入缓存或数据库有效期 2 分钟 cache(login_code_ . $login_code, 0, 120); // 返回二维码内容实际内容是一个带参数的 URL $qr_content url(wechat/scanLogin, [code $login_code], true, true); return json([code 0, qr_content $qr_content, login_code $login_code]); }这里cache()用的是 ThinkPHP 的缓存机制默认文件缓存即可。轮询接口负责把login_code变为已绑定状态的数据返回给 PC 端同时生成后台登录 session。容易出错的地方是二维码 URL 的域名本地调试时微信公众平台后台的回调域名不能配置localhost需要用内网穿透工具或者把校验文件放到服务器上开发阶段用测试号就能跳过这一步。4.3 预约数据可视化ECharts 图表统计项目技术栈里有 ECharts这部分一般放在后台首页展示场地预约热度、每日预约量趋势、场地使用率排行。后台接口返回统计数据的 JSON前端用 ECharts 渲染。常见统计口径有两个按日期统计每天的预约订单数按场地统计各场地的累计预约时长或次数。public function statistics() { // 近 7 天预约趋势 $start date(Y-m-d, strtotime(-7 days)); $list Db::name(reservation) -field(DATE_FORMAT(reserve_date, %m-%d) as date, COUNT(*) as total) -where(reserve_date, , $start) -where(status, 1) -group(reserve_date) -select() -toArray(); $trend []; for ($i 6; $i 0; $i--) { $d date(m-d, strtotime(-{$i} days)); $found array_filter($list, function ($v) use ($d) { return $v[date] $d; }); $trend[] [date $d, total $found ? array_values($found)[0][total] : 0]; } // 各场地使用率排行按预约次数 $venueRank Db::name(reservation) -alias(r) -join(venue v, r.venue_id v.id) -field(v.name, COUNT(*) as total) -where(r.status, 1) -group(r.venue_id) -order(total desc) -select() -toArray(); return json([code 0, trend $trend, venue_rank $venueRank]); }统计接口里有几个值得注意的细节DATE_FORMAT的格式化要在group和where中保持一致不然日期分组会产生错位近七天趋势的补零逻辑是把数据库查出的稀疏数据补齐为连续日期序列才能直接喂给 ECharts 的折线图使用率排行按预约次数统计是「次数口径」更精确的应该是按小时数统计即SUM(TIMESTAMPDIFF(...))看论文需要哪种口径就选哪种。前端 ECharts 渲染时要注意在管理后台的 Vue 组件中正确初始化图表实例import * as echarts from echarts; mounted() { this.initTrendChart(); }, methods: { initTrendChart() { const chart echarts.init(document.getElementById(trendChart)); // request 获取统计数据后 setOption chart.setOption({ tooltip: { trigger: axis }, xAxis: { type: category, data: this.trendDates }, yAxis: { type: value }, series: [{ type: line, data: this.trendCounts, areaStyle: {} }] }); } }mounted生命周期里初始化图表是正确位置不要在created里操作 DOM因为此时节点还没渲染出来。areaStyle让折线图带上渐变填充色视觉上更适合管理系统首页。Tab 页切换时注意图表宽度的自适应问题通常用window.onresize调用chart.resize()。5. 订单号生成策略与接口安全防护的进阶处理5.1 订单号的两种生成方式对比预约表里的order_no字段虽然只是业务编号但生成方式值得讲究。最省事的写法是上面提交预约接口里的date(YmdHis) . rand(1000, 9999)能保证基本唯一但在同一秒内并发提交时仍有碰撞可能。更稳妥的方式是用uniqid()配合md5散列或者用 ThinkPHP 自带的Db::name(reservation)-max(id) 1拼接日期前缀。业界常见的订单号规则是「日期 随机数 用户ID尾号」例如20240520183012888001。这种格式便于按日期范围模糊搜索也能从订单号反推用户维度做散列。这里给一个实际可用的生成函数function generateOrderNo($userId) { $datePart date(YmdHis); $randPart str_pad(mt_rand(0, 999999), 6, 0, STR_PAD_LEFT); $userPart str_pad($userId % 1000, 3, 0, STR_PAD_LEFT); return $datePart . $randPart . $userPart; }这个函数里str_pad保证了随机部分固定六位不会因为随机数小导致订单号长度不一致userId % 1000取用户 ID 后三位用于分库分表时的散列依据。毕设项目不涉及分库分表但生成逻辑保持规范总没坏处。5.2 接口防刷与身份校验预约系统面向全校师生接口安全性不能完全不管。最基础的三道防线是登录 token 校验、请求频率限制、关键操作二次验证。Token 校验用 ThinkPHP 中间件统一处理在application/http/middleware.php中注册class AuthMiddleware { public function handle($request, \Closure $next) { $token $request-header(authorization); $token str_replace(Bearer , , $token); $user Db::name(user)-where(token, $token)-find(); if (!$user) { return json([code 401, msg 请先登录]); } $request-user $user; return $next($request); } }请求频率限制的常见做法是记录每个 token 的接口调用时间戳一分钟内超过阈值直接拒绝。ThinkPHP 里可以用缓存实现$key rate_limit_ . $token; $count cache($key) ?: 0; if ($count 30) { return json([code 1, msg 请求过于频繁]); } cache($key, $count 1, 60);这种计数器模式的限流不是精确限流临界点可能放过少量请求但对毕设和校园内部系统够用。如果要做到更严格的滑动窗口或令牌桶就得引入 Redis 了项目复杂度会明显上升。5.3 部署上线时的 PHP 配置与常见坑本地跑通和真正部署到服务器是两回事。服务器上跑 ThinkPHP 项目php.ini的这几项配置直接影响系统是否正常file_uploads On upload_max_filesize 20M post_max_size 20M max_execution_time 60post_max_size必须大于upload_max_filesize否则上传场地图片时会报错。另外 ThinkPHP 5 需要开启伪静态Nginx 配置如下location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } }Apache 环境则是在项目根目录放.htaccess文件。很多人在本地用 phpStudy 的 Apache 跑没问题一到 Nginx 服务器上就 404基本都是伪静态没配。数据库连接配置里host不要写localhost在云服务器上写成127.0.0.1更可靠因为 PHP 在某些环境下解析localhost会优先走 IPv6 导致连接超时。5.4 演示视频录制与论文结构对应资源里带了演示视频和论文这两部分不是孤立的。录制演示视频时建议按照论文中的功能模块顺序操作先演示前台小程序注册登录再演示场地查询预约最后切到后台展示审核流程和图表统计这样评委看视频时能对应上论文结构。论文的核心章节安排一般是绪论、需求分析、系统设计、系统实现、系统测试其中「系统设计」对应数据库表结构设计「系统实现」对应每个功能模块的代码截图和页面截图。技术选型部分重点写明为什么用 PHP MySQL把 ThinkPHP 的优点和 MySQL 的适用场景写上就是论文里完整的可行性分析。本文还有配套的精品资源点击获取
