1. 选这个题之前我先想清楚了三件事每年毕业设计选题季总有人纠结要不要碰小程序方向。我的看法很直接如果你想要一个演示效果直观、技术范围可控、答辩有话讲、工作量看着不小的项目基于微信小程序的宠物店在线管理系统是一个性价比非常高的选择。它不像纯商城那样业务线单一也不像纯管理后台那样缺乏前端展示亮点而是把C端小程序购买体验和B端店铺经营管理两条线揉在一起正好覆盖了微信小程序开发、服务端接口设计、关系型数据库建模、管理端页面开发这些核心能力点。为什么特别适合毕设因为宠物店管理天然自带几个场景卖宠物用品算电商宠物洗澡美容要按体重计价寄养服务要按天排期疫苗提醒涉及时间计算会员储值和积分又是另一套规则。这些业务交叉在一起数据库表不会少接口不会只有增删改查论文研究现状和个人总结都有真实内容可以写。同类型的校园食堂订餐、二手交易平台也类似但宠物店在服务预约这一块多了一层排期复杂度稍微用心做就能和其他人拉开差距。我这边交付的源码工程结构已经整理成一套完整可运行的项目微信小程序端负责用户逛店、下单、预约Spring Boot 后端提供接口和业务逻辑管理端Vue 页面负责商品上架、订单处理和预约审核MySQL 脚本把建库建表语句也准备好了。接下来我按整个开发流程把每一步背后的设计逻辑和实操细节都拆开讲。1.1 为什么是宠物店管理系统而不是宠物商城很多人的第一反应是做一个宠物用品商城觉得商品展示、购物车、下单就够了。但这样做有一个问题商城类的毕设太常见评委老师看过太多论文里也很难写出有区分度的业务逻辑。宠物店在线管理系统和商城的本质区别在于它多了一条线性服务链用户在线上挑商品是第一条业务线预约到店服务洗澡、美容、寄养是第二条业务线两条线共享同一套用户体系和会员积分体系。举个例子宠物洗澡美容服务在真实门店里按宠物体重计费5公斤以下和10公斤以上的犬种洗护价格完全不同。这意味着系统里必须有一张宠物档案表记录每只宠物的品种、体重和年龄预约时要携带宠物档案数据后端再根据体重区间去计算服务价格。这一个点就能让你的数据库设计、接口逻辑和页面展示都比单纯卖货复杂一个档次而且符合行业实际答辩时讲我的系统按宠物体重自动匹配洗护价格是很有说服力的。再者宠物商品和宠物服务的数据模型差异很大。商品有规格、库存、物流属性服务有时间段、容量上限、服务时长、指定美容师。如果你只做商城这些差异根本体现不出来。所以我在设计需求时就明确系统至少包含用户端和管理端两个角色用户端覆盖首页、商品分类、购物车、订单、服务预约、宠物档案、会员中心管理端覆盖仪表盘、商品上下架、订单发货、预约审核、宠物档案管理、公告发布。功能闭环数据有来有回演示和论文都够用。1.2 技术选型原生小程序 Spring Boot MySQL技术栈的选择应该服务于两个目标第一是让你在有限时间内能把系统完整跑起来第二是答辩时能扛住追问。微信小程序端我用的是原生开发框架WXML、WXSS、JavaScript没有用 uni-app。原因很简单毕设项目不要求跨端发布到 App原生小程序在开发者工具里调试更直接页面结构和组件逻辑也能让老师看得更明白。如果你只会 Vue 的语法用 uni-app 也行但要注意编译后部分原生能力的适配问题比如自定义导航栏的胶囊按钮定位、onReachBottom 分页加载这些原生里都是现成事件uni-app 里反而要多包一层。后端我选了 Spring Boot MyBatis-Plus MySQL 8.0。Spring Boot 简化配置MyBatis-Plus 提供现成的单表 CRUD代码量能少写一半。为什么不选 Spring Security 做权限不是不行而是对毕设来说太重了配置和概念解释成本高一旦老师追问过滤器链执行顺序容易把自己绕进去。我用的是更轻量的 Token 拦截器方案用户登录成功后拿到一个 token后端写一个拦截器校验所有 /admin/** 接口的请求头逻辑简单代码也容易讲清楚。管理端用 Vue3 Element Plus 单独写一套页面打包后放到 Spring Boot 的静态资源目录里托管这样前后端部署是一体的演示时只需要起一个 jar 包不用再折腾 Nginx。如果时间紧张管理端也可以直接用 Thymeleaf 模板引擎写但页面观感会差一些。我在源码里提供的是 Vue 那套因为大多数毕设老师第一眼看的是界面光不光滑Element Plus 的表格、表单、弹窗组件能帮你省下大量调样式的时间。1.3 功能闭环不是堆页面而是让数据流动起来我在规划功能时有一个原则每个功能点必须能承接上一个功能产生的数据同时为下一个功能提供输入。具体来说用户在小程序端浏览商品、加入购物车、提交订单订单数据进入管理端的待发货列表用户给宠物创建档案、提交预约预约单进入管理端的待审核列表。管理端处理完订单和预约后数据状态回流到用户端的订单列表和预约记录里同时仪表盘上的销售额、预约量、热门商品排行榜也随之更新。这样做的好处是演示时有故事线我一边演示小程序下单一边切到管理端看到订单出现完成发货再切回小程序看到订单状态变化。数据在两端之间同步流动评委看完对整个系统的完整性会有直观印象。相反如果前端展示页和后台管理数据是割裂的只是各做各的 CRUD演示效果会非常碎。后面第 3 章我会讲到具体接口怎么对接第 4 章讲管理端怎么联动先把整体架构立住。2. 数据库设计整个项目能不能拿高分这一关是地基很多人写毕设拿到源码后第一件事就是跑起来看页面这是大忌。页面再好看数据库设计经不起推敲答辩一样扣分。我在宠物店系统里设计了 11 张核心表但更重要的是每张表为什么这么建、字段为什么这么设。把设计逻辑讲明白了老师问数据库相关问题你基本都能打住。2.1 核心表结构与字段规划用户体系这块用户表除了常规的 id、昵称、头像、手机号、注册时间之外还加了会员等级和积分两个字段。会员等级在用户端会有展示位积分来自消费和签到后续可以对接优惠券。但这里有一个细节会员等级和积分不要只放在用户表里。如果你后续要做消费满100元升级之类的规则等级和积分变动需要留痕所以单独建一张 member_log 表会更合理。我简化成了用户表直接存字段但你要清楚这个简化的代价——等级变更历史查不到。答辩时如果老师问你可以说这是为了控制毕设规模同时明确给出生产环境的扩展方案。宠物表是宠物店业务里最有辨识度的部分。字段包括 pet_id、user_id、宠物昵称、品种、生日、体重、绝育状态。其中体重字段非常关键因为洗护服务要按体重区间计价宠物档案里存了体重预约服务时就能自动匹配价格而不是让用户每次手动填写。绝育状态则关系到部分美容项目能否下单算一个小的业务规则点。商品与订单这边商品表走标准电商结构分类表、商品表、库存字段。但订单表有一个重要设计下单时要保存一份商品快照把下单时的商品名称、单价、图片都以冗余字段存进订单明细表。为什么因为商品表的价格会改、名称会调、图片会换如果订单明细只存商品 ID历史订单展示时可能拿到的是修改后的商品信息这与用户下单当时看到的不一致会造成对账困难。这个用业务数据快照可以解释得很清楚。2.2 订单状态机和预约排期逻辑我处理订单状态时用的是一张状态流转图虽然不能画流程图但你可以自己在纸上画出来待支付 - 已支付 - 已发货 - 已完成中间允许取消和退款。后端接口设计上每个状态变更对应一个独立的 action 接口比如 cancelOrder、payOrder、deliverOrder而不是写一个通用的 updateState 接口。为什么要这么设计因为每个 action 背后要做的校验和连带操作完全不同比如取消订单要回补库存退款要写退款记录并把积分扣回如果统一用一个状态更新接口逻辑会全部挤在一个方法里非常难维护。这也是一个小型系统里体现代码组织能力的点。预约逻辑是宠物店项目里的另一个亮点。预约表包含 user_id、pet_id、service_item_id、预约日期、时间段、状态等字段。一天的时间段是提前配置好的比如 09:00-10:00、10:00-11:00 这样划分。预约冲突检查的做法是当用户提交一个预约时后端先查该 day time_slot 下已审核通过的预约数量如果大于等于该服务项每天的最大容量就返回该时间段已约满。这里要注意并发问题如果两个用户同时提交同一个时间段的预约理论上会超卖。生产环境可以用数据库行锁或 Redis 计数器但毕设阶段我在代码里做了 synchronized 锁并加了唯一索引day、time_slot、service_item_id 组合实际并发测试问题不大也够答辩解释。2.3 预约服务按体重计价的业务亮点我前面几次提到按体重计价这里展开说一下具体实现。服务项目表里有一个 price_rule 字段存的是 JSON 格式的阶梯价格。比如美容服务的规则是 [{maxWeight: 5, price: 40}, {maxWeight: 10, price: 60}, {maxWeight: null, price: 80}]。当用户选择宠物并提交预约时后端从宠物档案里读取当前体重匹配对应区间的价格。这个设计比普通的价格字段灵活得多门店调整价格时不用改表结构直接改 JSON 规则即可。同时每次预约完成之后把实际成交价记录到预约单里。这样即使体重区间调价了历史预约单仍然保留当时的价格逻辑上和订单快照一致。这个点我在论文里单独写了一段基于规则引擎的宠物服务动态计价设计其实不算什么高深东西但写出来就显得你思考过业务细节。2.4 数据库设计的三个防坑提醒第一金额字段一律用 decimal(10, 2)不要用 float。float 是浮点数做加法会出现 0.1 0.2 不等于 0.3 这种精度问题金额算错在答辩现场非常尴尬。第二所有表统一加 create_time、update_time、is_deleted 三个通用字段。is_deleted 做逻辑删除配合 MyBatis-Plus 的 TableLogic 注解删数据变成改标记避免误删导致演示数据缺失。第三不要用物理外键。外键约束在删除或更新时会带来连锁问题而且 MyBatis-Plus 的批量操作很容易被外键卡住。表之间的关联关系靠查询时 join 字段来维护这是企业开发的常规做法你可以直接说电商系统分库分表后物理外键基本不可用所以用逻辑关联。3. 小程序端实现从工程目录到页面交互这些坑我都替你踩过小程序端是用户直接接触的部分也是毕设答辩时演示时间最长的界面。我按工程搭建 - 网络层封装 - 登录态 - 核心页面 - 适配细节这条线来讲每一步都有可以直接照抄的姿势。3.1 小程序工程结构怎么搭页面文件放在 pages 目录下按功能模块拆分子目录pages/index 首页、pages/category 分类、pages/cart 购物车、pages/order 订单列表、pages/order/detail 订单详情、pages/service 服务项目、pages/appointment 预约、pages/user 个人中心、pages/pet 宠物档案。组件放在 components 目录比如商品卡片、空状态占位、数量选择器、分页加载组件。utils 目录放三个文件request.js 统一请求封装、config.js 环境配置、util.js 工具函数格式化时间、价格展示、防抖。这里最容易被忽略的是 config.js 与环境切换。我建议配置一个全局变量里面包含 baseUrl 和图片前缀开发时指向你电脑的局域网 IP上线时改成服务器域名。小程序不支持运行时读取本地环境变量所以你得记住每次换环境要改这里。我在源码里把它单拎出来就是为了让你切换演示环境时不用到处找。3.2 网络请求封装和登录态处理request.js 里我做了几件事统一拼接 baseUrl读取 storage 里的 token 放到请求头响应非 200 时统一 toast 错误信息401 时清理登录态并跳转登录页。这个封装看起来基础但能避免你在每个页面重复写 wx.request而且统一报错样式。有一点要注意小程序里 wx.request 的 success 回调只是网络层成功不代表业务成功所以后端返回的数据要约定一个通用结构比如 { code: 0, data: ... }只有 code 为 0 才说明业务成功。不做这一层约定你会发现调试时错误信息全靠猜。登录流程是毕设必考点流程本身不复杂小程序端 wx.login 拿到临时 code传给后端 /api/login 接口后端拿这个 code 去微信服务器换 openid然后生成一个自己定义的 token 返回给小程序。这里有两个容易踩坑的地方第一wx.login 的 code 是一次性的5 分钟有效后端不要缓存第二新版本小程序不能再像以前那样直接 getUserInfo 弹窗获取用户头像和昵称现在更稳妥的做法是在个人中心页面放一个编辑资料功能让用户手动填写昵称、上传头像。微信官方对头像昵称填写能力做了调整你顺带在论文里写一句遵循微信平台最新的用户信息保护规范是比较加分的。3.3 首页、商品列表与分页加载首页做的内容比较标准顶部搜索框、轮播图用 swiper 组件、金刚区快捷入口、推荐商品流。轮播图的数据从管理端的公告管理接口读取图片上传后返回 URL。这里有一个性能小技巧首页的图片比较多时建议用小图压缩版不要直接加载原图。管理端上传图片后可以同时保存一个缩略图路径首页展示缩略图详情页展示原图减少小程序加载时间。商品分类页和搜索结果页共用一个商品列表组件这个组件里实现了分页加载小程序有 onReachBottom 页面生命周期当页面滚动到底部时触发加载下一页。我习惯用 page页码和 pageSize每页数量两个参数后端返回数据时同时返回 total前端根据 total 和已加载条数判断 hasMore 是否还有更多。这里的防坑点是onReachBottom 触发频率很高如果上一页请求还没返回就触发下一页会出现列表重复或错乱。解决办法是在组件里加一个 loading 标志位请求未完成时直接 return。下拉刷新用 enablePullDownRefresh 开启配置然后在 onPullDownRefresh 里重置页码并重新加载第一页数据。3.4 购物车、下单与预约流程的细节购物车数据建议存服务端而不是只存本地缓存。如果只存 localstorage用户换了手机登录购物车就丢了而且下单时校验库存还是得请求后端数据不同步会造成实际库存超卖。我的做法是购物车表关联用户 ID增删改都调用接口。购物车页面支持选中商品、修改数量、计算总价提交订单时只把选中的购物车 ID 列表传给后端后端在 service 层校验商品是否上下架、库存是否充足然后生成订单。这里下单接口里有一个关键动作先扣库存再写订单用事务包住任何一个步骤失败就整体回滚。实现时不要忘了在 service 方法上标注 Transactional。预约流程稍微不同因为它还要携带宠物 ID。用户从服务项目列表页进入详情页选择宠物从我的宠物档案里选选择日期和时间段提交后后端做容量校验然后创建一条待审核的预约单。管理端审核通过后用户端能通过订阅消息收到通知。小程序订阅消息wx.requestSubscribeMessage是毕设里容易被忽略的功能我建议你加上。它不需要额外的服务器资源前端拉起订阅授权后端调用 subscribeMessage.send 推送成本低但演示时很提气。3.5 自定义导航栏和相关适配问题把导航栏从默认样式改成自定义样式后页面上移会导致内容被状态栏和胶囊按钮遮挡。这个问题的关键在于动态获取胶囊按钮的位置和小程序右上角的胶囊布局信息。页面 json 里设置 navigationStyle: custom 后用 wx.getMenuButtonBoundingClientRect 获取胶囊按钮的坐标再从 wx.getSystemInfoSync 拿到状态栏高度计算出一个导航栏占位组件的高度并应用到每个页面的顶部。我在源码里写了一个 nav-bar 组件统一处理了标题显示和返回事件避免每个页面重复写。真机适配还有一个问题iPhone 底部横条home indicator会遮挡底部 tab 栏或底部操作按钮。解决方式是给底部区域加 padding-bottom: constant(safe-area-inset-bottom) 和 padding-bottom: env(safe-area-inset-bottom)。这两个 CSS 安全区属性虽然加了很久了但在小程序里仍然很常踩坑因为开发者工具的模拟器不一定能完全模拟真机的安全区表现演示时尽量用真机预览确认样式没问题。4. 管理端与接口开发内部人看的逻辑要配得上外部人看到的效果管理端是员工视角它不追求花哨但必须让每一项操作都有反馈。我在源码里提供了 Vue3 Element Plus 的管理端功能覆盖商品、订单、预约、会员、宠物档案、公告和统计数据。下面讲几个实现过程中花费时间最多、也最值得分享的模块。4.1 权限控制的轻量方案管理端登录走的是账号密码体系用户表和管理员表是分开的。管理员登录成功后后端生成一个包含 managerId 和 role 的 token 返回前端存到 localStorage并在每次请求时通过请求拦截器加入 Authorization 头。后端用一个拦截器拦截所有 /admin/** 接口从请求头里解析出 token如果无效或过期就返回 401。角色字段只区分超级管理员和普通员工超级管理员能访问商品删除、会员管理等高权限接口普通员工只能处理订单和预约。毕设这个权限粒度够了但你要讲清楚如果业务再复杂一点可以引入 RBAC 权限模型给每个管理员分配角色角色关联菜单和操作权限这样回答权限怎么扩展就有了现成答案。4.2 图片上传与静态资源映射管理端上传商品图片我用的是 el-upload 组件请求后端 /admin/file/upload 接口后端接收 MultipartFile保存到本地目录返回图片访问路径。这里有一个很常见的坑如果你将图片保存到项目的本地磁盘路径部署到服务器后路径会变或者你从开发电脑换到演示电脑后会发现所有历史图片全部裂图。我建议在 Spring Boot 配置文件里单独配置一个 upload.dir 属性同时自定义一个资源映射将 /upload/** 的 URL 映射到配置目录。也就是说代码里不要写死绝对路径全部读配置。另外小程序端和 web 管理端用的图片前缀可能不同前端展示时不要直接在代码里拼死前缀而是用接口返回的 URL 或统一前缀做拼接。我在 config.js 里单独留了 imgBaseUrl演示时改一处即可。图片上传大小也要限制。小程序端 wx.chooseMedia 可以选择压缩图片管理端上传时建议在后端设置单张不超过 2MB。如果你上传原图不压缩商品列表页加载大量高分辨率图用户体验会非常差小程序端流量消耗也大。我管理端里做了前端压缩并在后端做了大小校验双保险。4.3 订单处理与仪表盘统计订单管理页的核心操作是发货。点击发货后调用后端接口后端把订单状态改为已发货同时写入发货时间和物流单号。这里要处理一个关联逻辑用户端订单列表展示的是每个订单的最新状态订单状态一变小程序端要多拉一次接口才能看到最新状态。如果你想让演示更流畅可以在小程序端的订单列表页做一个下拉刷新并提醒用户刷新查看。很多毕设卡在这一步——发货了但小程序端看不到变化其实是前端没刷新数据不是后端 bug。仪表盘统计今日订单数、今日销售额、待发货订单数、待审核预约数这四个是顶部指标卡后端分别写 count / sum 查询。近 7 天销售趋势SQL 用 GROUP BY DATE(create_time) 统计每天的订单总额。热销商品 Top5按 order_item 里的商品 ID 分组count 数量降序。预约按服务项目分布查 appointment 表按 service_item_id 分组。这些统计接口看起来简单但实际会遇到一个问题本地订单数据量太少图表显示出来很稀疏演示效果不好。解决办法是在演示前准备一批有日期的模拟数据或者按日期范围筛选而不是只查最近 7 天。我在源码里写了一个数据导出的 SQL 脚本可以快速生成 20 条分布在不同日期的模拟订单方便演示时统计图有正常的曲线形状。5. 联调部署与常见问题排查实录5.1 域名与 HTTPS 配置小程序 wx.request 有个硬性要求正式环境请求的域名必须是 HTTPS并且在小程序管理后台配置 request 合法域名。毕设阶段如果你没有备案域名最简单的方案是使用开发者工具时在详情 - 本地设置里勾选不校验合法域名。但是要注意这个设置只对开发者工具生效真机预览时必须使用有效域名或者把后端地址配成局域网 IP 才能跑通。真机预览时你的手机和电脑必须在同一个局域网内后端运行在电脑上小程序请求地址填 http://你的电脑IP:8080。如果手机和电脑不在同一网络请求就会直接失败。我建议演示时把后端、小程序模拟器、管理端都集中在同一台电脑上避免网络问题影响发挥如果非要用真机演示请提前连好同一 Wi-Fi 并测试网络互通。5.2 真机预览与开发者工具的细节差异真机预览时有两个非常影响体验的问题。第一开发者工具模拟器里样式正常但真机上部分样式偏移常见的原因是字体渲染差异和 rpx 换算在不同屏幕宽度下的表现不同。第二真机上的 vConsole 工具可以看到 console.log 和网络请求但小程序开发工具里打开的调试面板和真机不完全一致。如果你遇到真机上有请求失败但模拟器正常优先检查网络环境、域名白名单、证书而不是怀疑后端代码。还有一个常见的缓存问题微信真机预览会缓存小程序代码包你改了代码后重新预览可能还是旧版本。解决方案是在预览二维码后在真机上杀掉小程序进程重新进入或者用体验版并清除缓存。5.3 常见问题速查表问题现象可能原因排查和处理方法模拟器请求接口直接报错本地设置未勾选不校验合法域名详情 - 本地设置 - 勾选不校验合法域名真机预览请求全部失败后端地址填成了 localhost改为电脑局域网 IP并确认手机和电脑同一 Wi-Fi登录接口报错拿不到用户信息wx.login 的 code 用错或过期每次登录都重新调用 wx.login代码不要缓存图片上传后显示裂图前端图片地址拼接错误或静态资源映射缺失检查图片 URL 是否完整、后端映射配置是否正确订单状态更新后小程序端看不到变化前端未重新拉取接口存在本地缓存小程序端做下拉刷新或每次页面展示时重新请求页面滚动底部重复加载列表缺少 loading 状态锁或 hasMore 判断在分页组件里加请求锁请求完成后更新 hasMore 标记6. 毕业设计答辩的演示策略这一块没人写但我建议你看完技术做完了论文写好了答辩现场如果翻车前面的努力全部白费。我根据自己的经验列几个演示时必须注意的点照着准备能少踩很多坑。6.1 演示前的准备工作提前半小时检查第一预置演示数据。数据库里至少要准备 15 个以上商品、5 只宠物档案、覆盖不同状态的订单待支付、已支付、已发货、已完成、已取消各来几条、未来几天的可预约时间段。很多项目在演示时用空数据库跑场景全凭现场新建一旦现场紧张操作缓慢整体效果就很拉胯。预置数据还有一个隐藏好处仪表盘的统计图表有真实数据曲线评委一看就觉得系统是被用过的。第二环境切换和网络检查。如果你之前一直用模拟器调试演示前最好先确定后端是否在当前电脑上运行数据库服务是否已启动。如果后端地址写的是 localhost切换到局域网 IP 后要记得同步更新 config.js 并重新编译。实操时我习惯准备一份启动文档把启动 MySQL、导入 SQL、启动 Spring Boot、启动管理端、打开微信开发者工具导入小程序这几步写清楚演示当天照着执行避免临时慌乱。第三准备一页演示脚本先展示小程序首页和商品分类再走一遍下单流程切到管理端处理订单再回到小程序看订单状态变化然后展示服务预约流程最后切到仪表盘看统计变化。脚本不用很详细但顺序要定好确保每一个功能点都有从前端到后端的闭环展示。答辩时时间有限演示流畅比功能齐全更重要。6.2 老师最爱问的几个问题提前背答案我把答辩现场被问到概率最高的问题整理成速答口径供你参考。你项目的登录流程是怎么实现的答小程序端 wx.login 获取临时 code后端用 code 换取 openid用 openid 作为用户唯一标识并签发自己的 token 管理登录态。要补充当前微信平台不再直接开放用户授权头像昵称的接口通过手动填写资料页解决。订单状态是怎么流转的画状态图说明待支付、已支付、已发货、已完成、已取消、已退款六种状态每种状态对应独立接口并解释取消订单回补库存、支付后扣减库存、退款扣回积分的联动逻辑。预约冲突怎么处理答提交预约时查询同一日期同一时间段已通过的预约数达到容量上限则拒绝数据库层用联合唯一索引兜底生产场景下可以用 Redis 计数器或数据库行锁但毕设项目用的是代码层面的校验加索引约束。你这个项目最大的难点是什么这个问题的标准答案不是学会了微信小程序语法而是挑一个业务复杂度高点讲清楚设计思路。我推荐答预约服务的动态计价服务项目价格规则用 JSON 配置宠物体重变化后重新匹配区间历史预约单保存成交价避免价格追溯困难。如果能把这个点讲明白老师会认可你是真的理解业务而不是只抄了一遍代码。7. 一些真实的心得留给准备动手的你文章写到最后一站分享几条我在开发和交付这个项目的过程中总结出来的真实经验。进度管理上我给自己的分期比是数据库设计和接口文档占四分之一小程序端实现占四分之二管理端和联调占四分之一。不要急着先写页面没有接口数据小程序页面写出来也只能用 mock 数据联调时还要返工。先把数据库的表建好、后端接口跑通让管理端能够维护数据再开始小程序端进度反而更快。协作习惯上建议全程用 Git 管理代码哪怕你是一个人写。每次完成一个模块就提交一次 commit理由有两个一是中途改坏了某项功能可以快速回退二是答辩老师的系统里会查代码提交记录有规律提交的 Git 历史会给独立完成、过程规范加分。提交信息开头用feat:、fix:这些前缀更显专业别一条消息写更新到底。源码交付的 Readme 一定要写清楚三块内容环境要求JDK 版本、Maven 版本、MySQL 版本、Node 版本、启动步骤建库、导入数据、修改配置、启动后端、导入小程序项目、测试账号信息管理端登录账号和密码。不要低估这一步很多同学在交付源码后被问的第一个问题就是怎么跑起来。把这块写明白对你负责对拿到你源码的人更负责。我做这个项目时最深的体会是毕业设计的评分标准本质上是你用工程方法解决一个具体问题的能力。宠物店管理系统这个题目并不新奇但只要你把完整链路走通把数据关系理清楚把演示故事讲流畅它就是一份扎实的、能拿得出手的成品。希望对正在选做这个方向的你有点实际帮助祝你答辩顺利。