★ FEATURED ARTICLE 这段时间不少读者和学弟学妹问到我去年做的那个毕业设计——基于微信小程序的宠物家一站式服务平台项目编号85422附带完整源码。今天就把它彻底拆开从选题思路、技术选型、数据库设计、核心功能实现到部署上线和答辩复盘一次性讲清楚。无论你是正在发愁毕设选题还是想梳理小程序全栈开发思路这篇文章应该都能帮上忙。当初选这个题目其实纯粹是被养宠物的亲戚朋友逼出来的。身边越来越多的人开始养猫养狗可宠物洗护要预约、驱虫疫苗要提醒、口粮猫砂要囤货信息散落在各家店面和群里沟通全靠加微信发消息体验很差。我意识到这里面缺一个“聚合入口”把服务预约、商品购买、养宠知识、在线客服整合到同一个平台里用户不用来回切换商家也能集中接单。用微信小程序承载这个入口非常合适用户无需单独下载App扫码即用对毕设而言也更容易在答辩时做真机演示。1. 项目概况与痛点分析1.1 为什么选“宠物服务小程序”这个组合做毕设最怕什么怕选题太空怕做出来一个别人已经做过八百遍的学生管理系统。我在选题前调研了一圈发现传统电商和外卖平台校园里做烂了而垂直领域的本地生活服务尤其针对宠物的反而还有不少可发挥的空间。所谓“一站式”我给它定的范围是三块服务预约宠物洗澡、美容、寄养、医疗检查、疫苗注射等线下服务的在线预约与订单管理。宠物商城猫粮狗粮、零食、玩具、日用消耗品的浏览、购买、支付和售后。内容与工具养宠百科文章、养宠提醒、附近门店信息、意见反馈。这个定位决定了它不是一个简单的CRUD练习而是涉及用户、宠物、门店、服务、商品、订单、支付、评价等多条业务线的综合体。对一个毕业设计来说工作量刚好能撑起一篇完整的论文也不至于大到做不完。1.2 系统角色与核心业务流程整个平台我划分了三种角色。用户端微信小程序消费者微信授权登录后可以管理自己的宠物档案按门店或服务项目预约浏览商城下单结算查看订单状态发表图文评价收藏商品和服务。商家端 / 店长端通过后台接收预约请求确认或拒绝订单管理门店服务项目、商品库存、上下架内容统计当日营收和预约到店情况。平台管理员审核门店入驻管理用户状态处理投诉反馈查看全局数据看板。核心业务闭环是这样的用户搜索/浏览服务 - 选择门店和时间段 - 提交预约生成待支付订单- 支付并锁定时段 - 商家接单 - 到店消费 - 服务完成 - 用户评价。商城的订单流程相应简单一些加购 - 下单支付 - 商家发货 - 确认收货 - 评价。这个流程和真实生活里的消费习惯是对齐的。我见过不少毕设把业务流程做得奇形怪状比如预约了不需要支付、订单完成了没有状态流转答辩时被老师一问就露馅。流程一定要完整哪怕功能做简单一点也比逻辑断裂强。2. 技术选型与开发环境2.1 前后端技术栈对比与选择这是我的踩坑重灾区。最初我纠结过用原生小程序还是跨端框架也纠结过用Java还是Node.js写后端。最后定下的组合是层面选型选择理由小程序前端微信原生WXML WXSS JS无需额外编译链路调试工具成熟出错好排查而且是毕设用原生最稳妥规避框架版本更新引发的坑后端Spring BootJava生态成熟分层规范论坛资料多遇到图书馆借的书足够解决数据库MySQL 8.0关系型数据模型清晰适合订单、用户等强一致场景缓存可选Redis用来缓存首页banner和热门服务提高读接口速度。不是重点没时间可砍云存储服务端存储/云对象存储商品图片和用户头像不能存本地小程序发布要求域名HTTPS这里直接买云存储最省心为什么不用uni-app如果是自己做着玩uni-app确实香一份代码多处运行。但毕设答辩主要考察你对某个平台的深入理解原生小程序更容易说到“生命周期、渲染机制、API调用”这些细节显得有深度。后端选Spring Boot而不是Node.js则是因为我对Java体系更熟校园里Java的参考资料多到数不清遇到问题不容易卡死。2.2 开发工具与环境搭建我本地的环境清单是这样的微信开发者工具稳定版即可调试小程序前端和真机预览IDEA社区版够了跑Spring Boot工程Navicat图形化操作MySQL建表建库快Jdk 1.8 / Maven 3.6 / Node.js后端构建工具链其实后端不依赖Node但小程序前端某些工具脚本会用到备着没坏处。一台云服务器用于部署后端接口内存2G以上环境搭建最花时间的坑是微信开发者工具里“不校验合法域名”的开关。本地调试时可以在详情 - 本地设置里勾选“不校验合法域名”不然所有请求都会被拦截。但上线前必须关掉这个开关并在小程序后台配置request和uploadFile的合法域名否则真机一访问就是白屏加报错。注意开发阶段后端接口一定要走局域网或内网穿透别在本地起一个localhost让手机访问那是必死的。我用的是把后端打包成jar扔到云服务器上跑前端直接请求服务器公网IP加端口这样真机调试和演示都稳。3. 数据库设计与API规划3.1 核心数据表结构数据库是整个系统的地基表结构设计的合不合理直接决定后面写业务代码是好受还是难受。我最终拆了近二十张表核心的这几张拿出来说说设计思路。用户表user字段名类型说明idbigint主键自增openidvarchar(64)微信唯一标识唯一索引nicknamevarchar(50)用户昵称avatar_urlvarchar(255)头像地址phonevarchar(20)手机号可空statustinyint0禁用 1正常create_timedatetime注册时间openid必须建唯一索引它是用户体系的主心骨。我一开始没建后来并发测试的时候出现同一个人注册出两条记录数据直接脏了。宠物档案表pet存放用户名下的宠物信息pet_name、pet_type猫/狗/其他、breed、gender、birthday、weight、avatar、user_id。这块很多人会漏但它是预约洗护类服务的前置条件预约时要选择对应宠物服务商才能提前准备。服务项目表service_itemstore_id、name、category洗护/美容/寄养/医疗、price、duration分钟、cover_image、description、sales_count、status。预约订单表appointment_order字段名类型说明idbigint主键order_novarchar(32)业务订单号唯一user_idbigint下单用户pet_idbigint关联的宠物store_idbigint门店service_idbigint服务项目appointment_timedatetime预约时间amountdecimal(10,2)金额statustinyint0待支付 1已支付 2已接单 3已完成 4已取消create_timedatetime下单时间这里我强烈建议用“业务订单号”而不是数据库自增ID作为前端展示和支付的凭证。自增ID一旦被刷出来很容易被恶意遍历查询数据。订单号我当时用时间戳加随机数生成简单够用。商品表goodsstore_id、goods_name、category、price、stock、cover_image、detail_images、sales_count、status。商城订单表mall_orderorder_no、user_id、store_id、total_amount、status待支付/已支付/已发货/已收货/已取消、receiver_name、receiver_phone、receiver_address。订单明细表mall_order_itemorder_id、goods_id、goods_name、goods_image、price、count。购物车结算时要拆成主单和明细这样订单详情页才能展示多个商品。其他还有store门店表、banner轮播图表、article百科文章、comment评论、collection收藏、cart购物车、admin_user管理员表、feedback意见反馈。每张表都配了create_time和update_time这个习惯帮我后面统计营收省了大力气。3.2 接口路径与鉴权设计接口我采用RESTful风格统一前缀 /api按模块拆文件。举几个例子POST /api/user/login微信登录换取平台会话tokenGET /api/banner/list获取首页轮播图GET /api/service/list分页查询服务项目支持按门店/品类过滤POST /api/appointment/create创建预约订单POST /api/appointment/pay模拟支付或发起微信支付GET /api/appointment/list按状态查用户预约列表POST /api/mall/order/create创建商城订单GET /api/mall/order/detail订单详情GET /api/admin/order/statistics管理员看板数据鉴权我在最开始时走了弯路直接用openid做身份凭证每次请求都拿openid去查用户非常蠢还把openid暴露在请求参数里。后来老老实实做了token机制登录接口返回一个含用户id和时间的加密字符串前端每次请求放在请求头的Authorization字段后端用拦截器校验token有效性。这一步很多同学容易跳过但答辩时老师说“怎么防止别人刷你的接口”你就知道有多重要了。4. 关键功能实现详解4.1 微信登录与用户体系建立微信小程序的登录流程是前端调用wx.login()获取临时code把code发给后端后端拿code appid secret调用微信接口换openid和session_key再用openid查用户表查到就更新登录态查不到就自动注册新用户。这一步有两个高频坑code5分钟有效只能用一次所以后端要尽快换openid别在中间塞一堆业务逻辑。appSecret绝不能放到小程序前端一定只在后端存。有人为了省事把appSecret写在request.js里上线后被调用接口公开售卖属于典型的安全事故。我封装了一个LoginUtil核心就几步// 根据前端的code调用微信接口换取openid String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code code grant_typeauthorization_code; String result HttpClientUtil.doGet(url); JSONObject json JSON.parseObject(result); String openid json.getString(openid);拿到openid后查user表存在则刷新最后登录时间不存在则new一个用户插入。然后生成自定义token比如用UUID或者JWT存Redis或者数据库并设置过期时间之后前端所有业务请求都带上token。有个细节微信昵称和头像在2021年之后不能在小程序前端通过getUserProfile直接弹窗获取了。我当时的方案是允许用户手动输入昵称、手动上传头像或者使用微信提供的头像昵称填写能力button open-typechooseAvatar input typenickname。这个变了很蠢一开始我的登录页卡了整整两天老代码报错新接口返回空真机测试各种不顺。4.2 服务预约与订单状态机预约功能是服务类型的核心。用户选好宠物、门店、服务项目之后要选择一个自己方便的时间段。我在数据库没有单独建“可预约时段表”而是在service_item表里存了duration预约时校验门店当天该时段是否已有冲突订单前端也限制只能选未来7天内的时间这样一套下来简单且够用。创建预约订单的接口我处理了两个关键点第一是库存/并发。同一个时段如果被两个人同时下单就会产生冲突。后端用事务和行锁解决查询该门店该时段是否有status为已支付或待支付且预约时间重叠的记录若有则抛出“该时间段已被预约”。因为订单表对store_id、appointment_time建了联合索引锁定范围小性能也不受影响。第二是主动关单。预约订单如果用户一直不支付会占用时段。我加了一个定时任务每5分钟扫描一次把超过15分钟未支付的待支付订单自动改为已取消释放时段。定时任务我用的Spring自带的Scheduled没引入额外的分布式任务框架毕设维度完全够用。Scheduled(cron 0 */5 * * * ?) public void cancelExpiredOrder() { // 查询所有 status0 且 create_time 小于当前时间-15分钟的订单 // 修改 status4并记日志 }预约状态流转我做了严格限制0待支付可以到1已支付或4已取消1已支付到2已接单或4已取消2到3已完成。商家端的接单接口会校验当前状态只能从1流转防止前置状态错乱。4.3 微信支付与退款流程支付是毕设里最容易被质疑真伪的环节。有的项目直接做一个假的“确认支付”按钮老师一眼就看穿。但真正接入微信支付需要商户号对于学生党来说确实有门槛。我的做法是双轨制订单支持微信支付与模拟支付两种模式通过配置文件开关切换。模拟支付逻辑很简单提交订单后跳到支付确认页点击“模拟支付”即调用后端接口将订单状态置为已支付并写入支付流水表。这个模式用于演示和答辩逻辑上同样校验了订单金额和订单归属不是随便改个状态依然能讲出完整的支付流程。微信支付真实对接时流程是后端调用统一下单接口 - 拿到prepay_id - 组装小程序端需要的支付参数 - 签名后返回前端 - 前端wx.requestPayment拉起支付面板 - 用户支付成功后微信服务器异步通知后端 - 后端验签后更新订单状态。这里最容易被坑的是签名。参数名必须按ASCII码排序拼接签名密钥不能泄露回调地址必须是HTTPS的。调试时微信商户平台的支付日志很关键能告诉你每一步到底发生了什么。当时我用官方SDK封装了一个PayService把签名逻辑收敛在一起出了问题只需要看日志排查。退款我简化处理了既然后端有了支付流水退款就写一个退款接口注意事务处理和幂等防止重复退款。毕设阶段不要求有完整的售后体系但退款这个功能如果答辩时被问到你必须说明白“钱从哪里来、回哪里去”所以我记录了流水表的原始金额和退款状态。4.4 管理后台与数据看板管理后台我用的是纯前后端分离的思路前端用经典的Vue2加Element UI开发部署时打包成静态文件和后端接口放在同一台服务器通过nginx转发。有的同学觉得毕设没必要做后端页面直接在数据库里改数据。我不推荐因为管理后台这部分在论文里至少能写一章而且老师的评语通常比较看重系统完整性。后台我实现了四块预约管理按门店和时间筛选订单商家可以接单、拒单。商品管理上下架、改库存、改价格库存不足时前端自动隐藏下架。内容管理编辑banner图、发布养宠百科文章。数据看板用ECharts画折线图展示近7天订单量和营收、饼图展示服务分类占比。数据看板接口返回数据其实很简单就是按时间聚合查询orders表并group by日期。但为了让答辩现场图表好看我额外存了一个统计表每天凌晨定时任务把前一天的订单汇总写入这样看板查询极快也不会因为大范围group by把主库拖慢。这是面试时可以说出口的设计思路。5. 部署上线与源码使用5.1 本地运行三步走拿到源码之后最快跑起来的方式就三步修改application.yml里的数据库用户名和密码导入数据库脚本脚本文件在源码目录sql目录下面。修改前端小程序 /utils/config.js里的baseUrl改成后端接口地址。微信开发者工具导入小程序前端目录开启本地调试模式比如勾选“不校验合法域名”。后端启动后访问Swagger接口文档地址源码里集成了knife4j能看到所有接口列表和请求示例核对一下接口是否正常。注意不同源码的配置结构可能略有差异项目里一般都有README说明文档先花五分钟读一下README再动手切忌直接双击工程就启动容易缺依赖。5.2 服务器部署注意点后端部署就一个jar包用maven package打出jar上传到服务器执行nohup java -jar pet-home-server.jar --server.port8080 。但如果你想用域名加HTTPS访问必须做三件事后端接口通过nginx反向代理到 8080 端口转发时处理跨域和WebSocket。小程序后台配置 request 合法域名指向你的域名且必须是HTTPS证书可以用免费赛门铁克或类似免费证书方案。服务器防火墙和云安全组放开 80 和 443 端口以及后端的8080端口如果用内网调用8080可以不对外开放。域名HTTPS的坑我实验了很多次才弄顺。小程序的request对域名有严格校验证书链不完整、域名少一层、甚至解析记录刚生效都会报错。调试HTTP请求失败时把报错信息截图到浏览器控制台看比在手机上瞎猜高效得多。给一个实用建议把后端写接口时同步维护一个文本文件记录每个接口的字段含义和返回示例。部署排错时这个文件就是你的宝藏地图不用反复翻代码。6. 毕设答辩常被追问的问题6.1 功能设计类问题我整理了答辩时被提问最多的问题你们可以提前准备。“为什么选择微信小程序而不是App”答开发成本低、免安装即用、微信生态入口丰富对本地生活类服务具有天然的流量优势原生小程序可以复用微信的用户体系授权即登录降低用户使用门槛。“预约服务的时段冲突是怎么解决的”答利用数据库事务加行锁查询指定门店、指定时间内状态为待支付或已支付的订单如果有重叠则终止下单同时定时任务处理未支付订单超时关闭。“如果同一个时段有两个人同时下单会不会有一方预约失败都不提示的情况”答锁定行后再校验事务中的第二条insert请求会被阻塞等待第一条提交后读到状态继续判断时段是否可用然后给出提示。不会出现两个人都预约成功。6.2 技术实现类问题“token校验失效后前端怎么处理”答后端拦截器返回401状态码前端响应拦截器统一捕获清除本地登录态并跳转登录页重新授权实现无感会话续期。“商品库存超卖怎么防止”答在update语句中增加库存条件判断比如update goods set stock stock - ? where id ? and stock ?受影响行数为0时说明库存不足需要回滚事务。“支付回调和主动查询如何配合”答前端在支付结果回调里调一次后端查询订单状态接口后端同时接受微信异步通知校验签名后更新订单状态并且为状态更新操作做好幂等控制。双通道保证极端情况不丢单。“如果没有商户号你的支付功能怎么演示”答系统内置了一个演示开关开启后支付走了本地模拟流程但后端依然严格按照真实支付流程的校验步骤执行如订单归属、金额一致、状态流转保证后续申请到商户号后可以无缝切换真实支付。如果你把这些问题提前写下来并对着代码过一遍到了答辩现场基本是不虚的。答辩老师不指望你做出一个商业化的系统更在意的是你是不是真的理解自己写的每一行代码。6.3 源码结构与复用建议源码目录可以从五个角度去理解小程序前端、后台管理端、后端服务端、数据库脚本、文档说明。整理清晰的分层会给你省下大量回忆时间写论文时参考代码结构也能直接梳理出系统架构图。如果你拿到同类的宠物平台源码别直接改个名字就交差至少要把首页文本、图片、门店信息替换掉并把数据库脚本重新执行一遍确认业务逻辑和数据能对上。答辩时如果老师突然问你某个门店的数据是怎么来的你卡壳就很尴尬。源码本身只是一个起点你得把它变成真正属于自己的项目。7. 常见报错与排错技巧实操过程中肯定遇到各种报错我挑五个高频问题做成速查表。现象原因排查解决方案小程序请求接口报“url not in domain list”合法域名未配置或本地校验开关没关开发阶段勾选不校验上线前配置HTTPS域名登录接口报code无效code一次性使用或已过期前端只调用一次wx.login后端立刻换取openid图片显示不出来图片URL域名未在小程序downloadFile合法域名中配置配置或改用云存储自带的https域名支付签名错误参数排列顺序或key错误打印传参严格按ASCII排序比对微信支付文档数据库时间差8小时服务器时区设置导致MySQL时间偏移设置jdbc连接串加serverTimezoneAsia/Shanghai排错建议遵循三步走先看后端控制台日志再看接口返回码最后看前端Network面板。很多同学一报错就蒙其实九成问题都能通过“看日志”定位。我再额外说一个经验开发阶段一定要把后端日志级别调到DEBUG不要嫌日志刷屏。尤其是Spring Boot里的SQL日志加上下面这行配置之后你可以清晰看到实际执行的SQL和参数排查哪里有逻辑问题特别快。logging: level: com.example.pethome.mapper: debug另外真机调试尽量用自己的手机不要整天用开发者工具的模拟器因为小程序在真机上网络请求、登录弹窗、支付行为均与模拟器有差异尤其是权限弹窗模拟器是跳过的。8. 从毕设到项目的几点体会做完这个宠物平台我最大的感受是毕设的本质不是向老师证明你会背知识点而是证明你有把一堆零散需求组织成完整系统的能力。过程中我深刻体会到需求边界的重要性。最初我把评论、社区、拼团、秒杀全加了进去结果开发节奏被拖得极其难受。后来冷静下来砍掉社区和拼团专注把服务预约和商城的主链路做深做透系统反而更像样。做项目要懂得取舍十个半成品不如五个完整闭环。另一个心得是文档要边写代码边整理。我一开始对论文完全没感觉后来每实现一个功能就顺手记录关键代码片段、接口参数、遇到的坑等开始写论文时材料都现成了节省了大量时间。源码880行注释也很大程度上是那个时候补的。最后分享一个小技巧给你的后端接口写一个健康检查接口比如GET /api/health返回“ok 系统时间”。部署完第一时间访问它能快速判断服务是否起来答辩前也先点一下它确保后端在线别等演示时接口全挂。这个小习惯帮我避免了好几次演示事故。如果你们也在做类似的微信小程序毕业设计希望这篇长文能给你一个相对清晰的路标。项目编号85422对应的完整源码和数据库脚本都打包在那个压缩包里了下载后先跑通再改业务比从零开始省力得多。遇到具体报错也可以把日志贴出来大家一起讨论踩坑经验这东西分享出来才值钱。
阅读完成 · 觉得有帮助？
