1. 这个选题值不值得做聊聊“SpringBoot商城微信小程序”在毕业设计中的分量带过几届计算机专业的毕设我越来越发现一个规律选题方向直接决定你剩下五个月是活得轻松还是过得痛苦。而“SpringBoot商城微信小程序”这个题目属于那种“看起来满大街都是但真正能做出层次感的人并不多”的典型选题。为什么这么说因为它踩中了毕业设计评分体系里的三个关键维度技术栈主流、业务闭环完整、有天然的可扩展空间。先说技术栈主流这件事。SpringBoot是当前企业级Java后端的事实标准几乎每一份实习招聘JD里都会出现它的名字导师看到这个技术选型不会有任何质疑。微信小程序又是国内用户量最大的轻应用形态你在简历上写“独立开发过微信小程序商城”面试官至少会愿意多问两句。而SpringBoot 微信小程序这个组合天然覆盖了前后端分离开发、HTTP接口设计、数据持久化、移动端适配、第三方平台对接等核心技能点一次毕设下来你简历上能填的内容能厚实不少。再说业务闭环。商城系统有一个其他选题很难替代的优势它包含了电商领域的完整业务链路——用户注册登录、商品浏览、购物车管理、订单生成、支付对接、库存扣减、售后状态流转。这条链路从用户角度是“逛一下然后买下东西”从技术角度却是十几个相互关联的接口模块。这意味着你的课题工作量天然饱满中期检查汇报时你能拿出东西展示最终答辩时也有讲不完的细节可以展开不会出现“做了一个管理系统但只有增删改查”那种三分钟说完然后全场沉默的尴尬局面。我带过的学生里凡是选商城类题目的评审时被追问的问题大多集中在业务逻辑本身比如并发下单怎么处理、购物车过期怎么办、支付回调怎么保证幂等这些问题只要你真的动手写过代码回答起来都不慌。至于“源码34906”这个编号通常意味着平台收录的源码资源编号。很多同学拿到一份源码之后最常犯的错误就是把它当成交作业的终稿来用——改个名字、换几张图片、提交完事结果答辩时被导师一问“这个表为什么这么设计”就卡住了。这套东西的正确用法是把它当一份可运行的骨架和参考答案你要能把它讲清楚、改得动、跑得起来甚至替换掉其中核心模块自己重写一遍。源码本身不产生价值你对源码的理解、改造和演示能力才产生价值。结论先放在这里如果你已经拿到了这套主题的源码或者正打算选购类似方向的资源这是个值得认真做的选题。但前提是你要真的理解整个系统的每一层是怎么运转的。这篇文章我就按我实际带学生完成这个项目的顺序把从环境准备、数据库建模、后端接口、小程序端到部署答辩的全过程拆开讲包括那些常规文档里不会写的坑。2. 开工前最该想清楚的三件事版本选型、工具链和代码结构很多同学拿到源码后第一反应是双击打开idea就开始跑然后被一连串的报错砸到怀疑人生。根据我的经验真正熟练的人拿到项目源码后的第一件事是花二十分钟把环境要求和依赖版本看清楚再决定哪些要重装、哪些要降级、哪些干脆替换掉。磨刀不误砍柴工这一节我先带你把这层地基铺好。2.1 SpringBoot版本是第一步大坑2.x还是3.x我在指导毕设的过程中见到过太多次这种场景学生照着网上的教程装的是JDK 17 SpringBoot 3.x然后打开网上下载的毕设源码发现用的是SpringBoot 2.xpom文件一堆依赖冲突代码里很多写法在3.x下直接编译不过。你要明白一个基本事实目前在各类毕设源码平台流通的项目绝大部分还是基于SpringBoot 2.x开发的尤其是2.6.x和2.7.x这两个小版本生态成熟、资料多、踩坑案例丰富尤其适合毕设这种“时间紧、求稳”的场景。我给你的建议很直接不要贸然升级到SpringBoot 3.x。SpringBoot 3.0要求JDK 17起步并且把javax.包迁移到了jakarta.光是import语句的大批量调整就足够让你烦躁一晚上。而且很多第三方整合组件在3.x下还没有完全跟上节奏你会在“找依赖jar包”这件事上耗费大量时间。如果你拿到的源码是基于2.x的老老实实用JDK 8或JDK 11 SpringBoot 2.7.x这是全天下最稳的组合。当然如果你是从零自己写项目倒是可以考虑直接上SpringBoot 3.x JDK 17毕竟毕业之后进企业大概率也会用到新版提前熟悉没有坏处但既然你手里已经有源码以稳定跑通为第一目标版本选择就要保守。2.2 工具链清单每个人都能低成本复现这里列一下我实际跑通这套毕设时使用的软件环境全部以主流免费工具为准。项目工程本身我建议用IntelliJ IDEA社区版或旗舰版旗舰版对SpringBoot的调试支持更强但我带的学生也有用社区版一路做下来的核心功能不受影响。数据库这一块MySQL 5.7或8.0都行考虑到毕设评分有时候会涉及环境迁移我倾向于推荐MySQL 8.0但如果你在Windows上安装8.0时遇到服务无法启动之类的兼容问题退到5.7也是合理选择两个版本在这套项目中的表现没有本质差异。数据库管理工具我习惯用Navicat界面直观导出导入方便适合中期给导师截图展示ER图和表结构。但如果你不想为Navicat的授权费心可以用MySQL官方自带的Workbench或者使用IDEA内置的Database面板完全够用。小程序前端开发这一侧微信开发者工具是唯一正解这个没什么好犹豫的直接在官网下载稳定版即可。最后是JDK千万别装最新的JDK 21来跑SpringBoot 2.x的项目老老实实用JDK 8或JDK 11我见过太多学生用新JDK跑旧项目最后折腾半天发现是JDK版本导致编译报错的。组件推荐版本说明JDK1.8即Java 8或11跑SpringBoot 2.x项目的稳选SpringBoot2.7.x生态成熟、与源码兼容性最好MySQL8.0或5.7两者在这套项目中表现一致IDEA2023.x及以上社区版完全可以覆盖需求微信开发者工具最新稳定版调试小程序端的核心工具2.3 pom.xml依赖层面的“排雷”检查清单拿到源码后别急着点运行先打开pom.xml扫一遍依赖。正常的毕设商城项目核心依赖至少包含这几个模块spring-boot-starter-web提供Web能力和内嵌Tomcat、spring-boot-starter-data-redis做缓存和购物车会话如果项目用了的话、MyBatis或MyBatis-Plus操作数据库、mysql-connector-j数据库驱动、fastjson或JacksonJSON序列化。如果你看到项目用了Druid连接池那也没问题这是国内很常见的配置方式。这一轮检查中最经典的一个坑是“Java项目报找不到javax.servlet”或者“程序包javax.annotation不存在”这一类问题八成出在JDK版本和SpringBoot版本不匹配上。解决办法优先级排序是调整JDK版本 → 调整SpringBoot版本 → 调整依赖版本不要一上来就改代码。另外一个常见的坑是MyBatis-Plus和MyBatis的版本冲突如果你发现mapper接口扫描异常多半是pom里同时引入了两套MyBatis相关的依赖这里只保留MyBatis-Plus或者只保留MyBatis别让它们共存。3. 从购物场景反推数据库建模一张表一张表说清楚为什么这么设计商城系统的数据库表设计是答辩时导师最喜欢深挖的部分。很多同学抄完源码能跑起来但被问到“为什么要建这张表”“这个字段有什么用”时支支吾吾这非常扣分。别慌只要从业务场景出发每一张表的存在理由其实都非常直白。我把这套商城毕设里的核心表拆给你看你理解之后无论导师怎么问都能从容接住。3.1 用户侧用户表、收货地址表和购物车表的设计逻辑用户表user大概是整个项目里最简单但最必要的表它承载的是小程序端登录后的用户档案。字段一般包含主键id、微信小程序openid这是用户在你这个小程序里的唯一身份标识、昵称nickname、头像avatar_url、手机号phone、注册时间create_time。这里最关键的字段是openid它来自微信登录时通过wx.login拿到的code再换取的会话标识。很多同学在这个地方容易把unionid和openid搞混简单说openid是同一个微信用户在你这个应用内的唯一IDunionid是同一个微信用户在同一个开放平台账号下的多个应用之间的统一ID我们的商城场景只需要关注openid就足够了。收货地址表address的逻辑更贴近日常一个用户可以有多个收货地址所以通过user_id关联用户表再记录收货人姓名receiver_name、手机号receiver_phone、省市区province、city、district、详细地址detail、是否默认地址is_default。这里有一个经验之谈下单时一定要把地址信息“快照”一份到订单表里而不是下单后实时去地址表查询。原因很真实——用户可能在下单后修改了地址但订单已经进入了物流流程必须使用下单那一刻的地址信息。这个设计在答辩时提出来会很加分因为这说明你考虑到了数据一致性的现实问题。购物车表cart则是典型的用户状态表id、user_id、product_id、quantity数量、checked是否选中、create_time、update_time。注意购物车表在逻辑上是“用户—商品”多对多关系的一个中间态载体它不需要独立保存商品价格因为商品价格变动频繁购物车只负责记录“用户打算买什么、买多少”真正的价格核算发生在购物车结算或生成订单那一刻从商品表实时读取。这个取舍为什么重要因为商品搞促销打折、管理员调整价格是很常见的事情如果购物车里冗余存了价格就很容易出现“加购时一个价、结算时另一个价”的数据不一致问题这恰好是面试官和导师喜欢追问的点。3.2 商品侧分类表、商品表和轮播图表的关系商品分类表category字段很清晰id、category_name分类名称、parent_id父分类id、sort_order排序权重。支持parent_id这一步意味着你可以把分类做成两级结构比如“手机数码”下挂“手机”“平板”“笔记本”子分类。关于是否需要无限级分类我的建议是不要。毕设这个体量做成一级或两级分类已经足够展示设计能力无限级递归会大幅增加前后端联调的复杂度对最终评分帮助极其有限性价比不高。商品表product是本系统的核心数据表字段多一些没关系但每个都要能讲出用途。核心字段包括id、title商品标题、subtitle副标题或卖点描述、main_image主图、detail_images详情图通常以JSON数组字符串存储、price当前售价、original_price划线价用于显示折扣效果、stock库存数量、sales销量、category_id所属分类、status上下架状态1上架0下架、create_time、update_time。这里值得多说一句的是库存字段。为什么不下单时直接扣减库存而是在订单生成后二次确认因为用户可能把商品放购物车里很久或者多个用户同时看同一件商品如果库存被扣得太早会导致“下单了但没付款”的商品也占着库存卖家的损失得由系统设计来背典型的案例就是秒杀场景下的超卖问题。毕设虽然没有必要做到分布式锁级别的高并发方案但至少要在代码层面判断库存是否足够并在扣减时使用update语句携带库存条件来确保并发安全这种细节讲到答辩评委面前专业感立刻不一样。轮播图表banner单独建一张表很多同学不理解理由是“轮播图不就是几张图片吗”。但在真实运营场景里轮播图需要区分位置、设置跳转商品或活动页面、控制上下线时间它本质上是运营位而非商品属性。字段设计为id、image_url、link_type跳转类型如商品详情、分类页、店铺首页等、link_target跳转目标id、sort_order、status、start_time、end_time。能够用独立表管理首页内容位而不是把轮播图写死在代码里这个设计理念本身就是加分项说明你对“运营可配置化”有意识。3.3 订单侧购物车结算为什么要拆出订单表和订单明细表这是整个数据库设计的核心知识点几乎是导师最爱的提问点——订单表order和订单明细表order_item为什么要拆成两张表答案用一个生活场景就能说清你和同事拼单买了两件衣服一起下单收货地址是同一个但在商家后台这两件衣服分别归属于不同仓库。你的“一个订单”是一个逻辑上的购物行为而“衣服A发A仓、衣服B发B仓”是物理上的履约行为。用一个超简单的类比来记就是订单表管“谁买的、买了什么总价多少、送到哪”订单明细表管“具体每一件商品、数量、单价、小计”。两者是一对多的关系order_id作为订单明细表的外键。订单表order字段设计id、order_number订单编号唯一通常用时间戳随机数生成、user_id下单用户、total_amount订单总金额、actual_amount实付金额通常与total_amount相同但如果做了满减优惠或改价就用这个字段、status订单状态一般用枚举整数0待付款、1待发货、2待收货、3已完成、4已取消、5售后/退款中、receiver_name、receiver_phone、receiver_address这三者是下单时收货地址的快照、create_time、pay_time、ship_time、complete_time。为什么要有这么多时间字段因为答辩时你不需要用嘴说明“我把订单状态流转做得很完整”只要把表结构亮出来这些时间字段本身就是证据。订单明细表order_item字段设计id、order_id关联订单表、product_id、product_title商品标题快照、product_image商品图片快照、price成交单价快照、quantity购买数量、total_price小计。注意我反复提到“快照”这个词因为商品标题、图片、价格都是可能发生变化的——商家修改了标题、换了主图、调整了售价历史订单绝不能跟着变。电商行业处理这种问题的标准做法就是冗余快照字段。你在答辩中说一句“我对商品信息做了下单时刻的快照避免历史订单信息被商品维护影响”这一句话的效率抵得上你背五段理论。订单表与订单明细表的关系必须放在答辩材料里明确展示我一般建议学生画一张简单的关系图user表1对多order表order表1对多order_item表product表1对多order_item表。业务上order_item还有一个隐含作用就是支撑“统计热销商品”“分析用户偏好”这类数据库题目中常见的延伸功能如果你有余力可以用这几张表配合写一段统计SQL比如按照销量列出TOP10商品这也是很好的加分亮点。4. 后端接口开发SpringBoot商城系统的关键链路实现搞定了数据模型接下来就是后端接口的编码环节。一个标准的毕设商城后端接口数量通常在30到50个之间如果太多说明你把不该拆的拆了太少则有凑数嫌疑。这里我不按文件逐个罗列而是按“一条完整的购物路径”来拆。你照着这条路径走一遍整个后端骨架就有了。4.1 注册登录链路小程序端wx.login到数据库user表的落库小程序的登录逻辑和普通网页的账号密码登录完全不同核心在于微信已经替你做完了身份认证你只需要通过微信官方接口拿到这个用户在你这边的唯一标识。完整链路是小程序端调用wx.login()获取一个临时凭证code → 小程序端把这个code通过自己后端接口传给服务器 → 后端拿着code调用微信官方接口jscode2session请求格式是appid secret code换取到这个用户的openid和session_key → 后端拿着openid去user表查如果查不到说明这是新用户直接帮他创建一个默认账号并落库如果查到了直接视为登录成功 → 后端生成一个自定义登录态返回给小程序端一般是一个token后续请求在请求头中携带它来识别用户身份。这个流程在后端落地时有几个细节值得你格外注意。第一个是code只能使用一次有效期只有几分钟所以后端拿到code之后必须立即去换openid不要做缓存。第二个是session_key属于敏感信息它可用于后续解密手机号等操作但要遵循“用后即弃”原则不要轻易暴露给前端。第三个是每个小程序都有自己的appid和secret你需要在配置文件里维护好这两项同时注意不要把secret明文写在前端代码里否则任何人都能获取你的secret去冒充你的服务器调用微信接口。在整个链路里token的生成方式我推荐使用UUID无脑生成即可但更好的做法是引入JWT把用户id、过期时间等信息编码进token这样做的好处是用户登录态里自带信息后端每次校验只需要解析token而不必查数据库。毕设做到JWT这一步基本上已经是“超越基本要求”的档次了。4.2 商品浏览与购物车链路从列表接口到购物车状态维护商品列表接口的设计有一个任何毕设学生都必须面对的需求——分页。千万不要一次性把全表数据都查出来扔给前端商品数据稍微多一点小程序端就会肉眼可见地卡顿。我建议使用MyBatis-Plus自带的分页插件一条Page对象传进去返回UserPage和记录列表即可。在分页之外还可以提供分类id参数作为过滤条件同时支持关键词搜索和排序字段比如按销量排序或按价格排序这几个维度加起来商品列表接口就算完成了。商品详情接口相对简单根据product_id查出一条商品记录把商品图、详情图、价格、库存一并返回。但这里有一个卡顿隐患值得提醒如果你的商品详情图是远程图片地址且有十几张小程序端一次性加载会让用户等待特别久。我见过不少同学在这个问题上栽跟头事实上解决方式非常简单采用懒加载模式或分批加载图片或者在后端接口中直接按需截取前N张都能换来显著的体验提升。购物车这块的后端接口一共四个加入购物车、查询购物车列表、修改购物车商品数量或选中状态、删除购物车项。加入购物车有一个需要你设计的业务问题同一用户反复点击同一商品的“加入购物车”是新增一条记录还是在原有记录上累加数量正确答案是后者否则用户的购物车会膨胀得难以管理。这个判断可以通过user_id product_id联合查询来实现存在则数量加1不存在则插入新记录。查询购物车时后端最好直接返回商品当前的最新价格和上下架状态因为购物车里的价格是“快照前的参考信息”小程序端结算用的价格一定要以后端返回为准这里的逻辑和前面讲到数据库设计时的价格处理是一套思路前后呼应答辩时你甚至可以主动把这个点提出来讲显得你思路非常完整。4.3 订单与支付链路库存扣减、订单生成和支付回调怎么保证数据一致下单接口被称为“高并发场景下最容易出问题”的接口这句话在毕业设计中同样适用。正常的业务流程是小程序端提交“结算”请求后端收到购物车中选中的商品id列表 → 后端根据商品id批量读取最新的商品信息和库存 → 计算总金额 → 检查并扣减库存 → 生成订单主记录 → 批量生成订单明细记录 → 清空购物车中对应商品 → 返回订单号和订单id给前端。在这个链路中最需要小心的是库存扣减这一步。我曾经见过有学生的下单接口把库存修改写成了UPDATE product SET stock stock - 1 WHERE id ?不判断库存是否足够结果就是库存变成负数被导师当场抓包。正确的做法是执行条件更新代码模板是UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}这句话的返回结果如果是1说明扣减成功如果是0说明库存不足此时要立即回滚整个事务。同时下单这个操作涉及多张表的写操作必须开启数据库事务用Spring的Transactional注解即可。在事务的保护下扣库存和生成订单这两个步骤要么全部成功要么全部回滚不会产生中间状态。支付这一块是整个毕设中最容易卡住的地方。微信支付申请商户号需要企业资质很多学生没有营业执照个人主体无法直接接入真正的微信支付。这里我的建议是不要硬刚直接用模拟支付方案。小程序端点击“去支付”后跳到一个模拟收银台页面展示应付款金额和两个按钮——“模拟支付成功”“模拟支付失败”。点“模拟支付成功”后小程序端调用后端的“支付结果通知”接口后端把订单状态从“待付款”更新为“待发货”同时记录支付时间。用这种方式既能完整展示订单状态机的运转又不依赖真实商户资质毕设评分中不会因此丢分。答辩时如果老师问到“为什么不做真实支付”你就如实回答“微信支付需要企业资质个人开发者环境无法申请因此采用模拟支付流程来复现业务闭环”这个说法既坦诚又没有硬伤老师基本都能理解。如果你有企业资质确实想对接真实支付那你就需要走正规的微信支付流程后端调用统一下单接口获取prepay_id再使用签名算法生成支付参数返回给小程序端小程序端调用wx.requestPayment拉起支付面板用户完成支付后微信服务器会异步通知你设置的支付回调URL后端在回调中验签并更新订单状态。这里有一个高阶经验一定要记住回调通知可能会到达多次后端必须保证重复回调不引发重复更新业界做法是在处理回调前先判断订单的当前状态只有“待付款”状态才允许被更新为“待发货”否则直接返回成功应答。这样你整个支付链路就是幂等的不会因为网络重试导致数据错乱。5. 小程序端开发从登录授权到商城页面落地的完整跑通后端接口就绪后工作重心要转移到微信开发者工具这边。小程序端的核心代码结构通常包含pages目录每个页面一个文件夹、components目录自定义组件、utils目录封装请求函数、api目录集中管理接口定义。我按一个用户的浏览购物路径带你走一遍每个关键页面应该长什么样、里面藏着哪些坑。5.1 全局配置和请求封装app.js、app.json、request.js小程序的全局配置文件app.json管的是整个应用的页面路由、窗口样式、tabBar底部导航。一个商城小程序的tabBar通常包含四个入口首页、分类、购物车、我的对应四个页面路径。app.js里放的是全局生命周期逻辑启动时获取系统信息、计算顶部导航栏高度登录态信息也在app.js里管理可以存在globalData中方便各页面直接访问。请求封装这一步是拉开代码水平差距的地方。建议在utils/request.js中封装统一的http工具函数对wx.request做一层promise化包装这样每个页面调用时只需要api.getList(params)代码会很清爽。封装时要在拦截器中统一做几件事把存储的token放进请求头Authorization字段遇到HTTP 401状态码时自动跳转到登录页遇到业务码非0时统一弹出Toast提示错误信息。这套封装逻辑虽然简单但属于“看似不起眼、实则体验大提升”的操作评审时能被一眼识别出你的工程化意识。小程序的登录态存储还有一个微信特有的坑要注意任何把token存进Storage的步骤之后都必须确认后续请求确实能够在请求头中带上这个token。我见过好多学生的代码登录成功跳回首页后首页请求却仍然返回401排查半天发现是请求封装里没有统一加token导致。这个环节不要偷懒登录成功写Storage请求封装统一读取Storage两段代码都要自己写一遍就永远不会出现这种问题了。5.2 四个核心页面的职责划分和交互细节先说tabBar四个页面。首页home的核心是展示轮播图和商品列表轮播图数据从banner接口获取商品列表采取上拉加载更多的方式触底时自动请求下一页数据这个交互是电商小程序的标准形态实现的来源是页面位置监听。分类页category的交互模式常见的是左侧一级分类导航栏、右侧二级分类商品列表的布局左右联动是判断该页面质量的重要标尺实现思路是点击左侧分类时右侧列表请到对应分类下的商品数据并刷新。购物车页面cart展示当前用户的购物车列表每行商品包含选中复选框、图片、标题、价格、数量增减器和删除按钮需要支持全选、批量删除和合计金额动态计算。个人中心页面mine展示用户头像昵称、我的订单入口、收货地址管理入口和售后入口订单部分通常按状态分组展示为“待付款”“待发货”“待收货”“已完成”四个标签页点击可跳到对应的订单列表页。除了这四个tabBar页面还有几个功能页面不能少商品列表页search、商品详情页detail、确认订单页settle、订单列表页orderList、订单详情页orderDetail、收货地址编辑页addressEdit。商品详情页是整个商城小程序中最复杂也最值得打磨的页面它包含商品轮播图展示、价格信息、标题描述、库存提示、商品详情富文本、底部“加入购物车”和“立即购买”双按钮。这里的经典交互是点击“立即购买”时弹出一个SKU选择面板用户选好规格后直接进入确认订单流程点击“加入购物车”则复用同一个弹窗选好规格后直接调加入购物车接口。SKU那块能做出正确联动需要比较细心但毕设项目中即便只做单一规格商品也是说得过去的根据你自己的精力来定。5.3 登录授权的一个细节坑手机号获取从基础库升级就必须调新版组件小程序历史上有段时间获取用户手机号可以通过wx.getPhoneNumber按钮授权后直接拿到加密数据再配合后端解密得到手机号。但新版基础库已经全面切换到“手机号快速验证组件”需要在页面的button组件上加open-typegetPhoneNumber属性然后监听bindgetphonenumber事件通过事件回调里返回的code传给后端再由后端调用微信接口换取手机号。太多学生还在翻旧的教程按老接口写结果真机调试时发现拿不到手机号一查版本又懵了。这里提醒键盘敲完之前先确认你手头参考教程的时效性最简单的方式就是在微信官方文档中搜“手机号快速验证组件”以官方最新说明为准。登录授权还有一个真实体验层面的教训不要在用户刚进入小程序时就直接弹窗强制要求授权手机号。微信审核和用户满意度都会因此打折扣正确的时机是在用户下单结算时自然引导授权。第一次登录只需要静默登录拿到用户唯一标识即可不需要手机号的环节用不到这个能力。先跑通静默登录再按需引导手机号授权这才是符合平台规范和用户习惯的做法。6. 部署、调试和答辩真正拉开差距的地方源码能跑通只是及格线真正拉开分差的是你的部署能力和你对项目的解释能力。这一节我把从本地启动到线上部署再到答辩准备的完整路径走一遍顺便把那些能救命的坑全部写出来。6.1 本地跑通的十步法和三个高频报错第一步在MySQL里新建一个数据库名字可以叫mall把源代码附带的sql脚本导入。打开sql文件你会发现它通常包含建表语句和测试数据不要只导结构不导数据否则前端页面没有商品展示你无法验证接口逻辑。第二步用IDEA打开后端工程等待Maven依赖下载完成这一步通常需要几分钟如果下载速度慢给Maven配置阿里云镜像。第三步修改application.yml配置文件的数据库连接信息把username、password改成你本地的实际值。第四步在application.yml里检查redis相关配置如果项目用了Redis就启动本地的Redis服务注意Windows上没有官方Redis安装包可以下载Redis的Windows移植版或使用WSL运行。第五步在IDEA中启动Application主类观察控制台日志出现Tomcat started字样即为启动成功。第六步下载并安装微信开发者工具导入小程序前端工程directory注意选择“小程序项目”而非“小游戏项目”。第七步打开app.js或config文件把后端的接口地址改为localhost对应的端口比如http://localhost:8080。第八步在微信开发者工具的“详情-本地设置”里勾选“不校验合法域名”这个选项允许你在开发阶段访问任意http地址。第九步点击“编译”等待小程序端渲染完成。第十步从注册登录到商品下单走一遍完整的购物流程把报错逐条修完。这十步中最常见的两个报错我提前给你排掉。第一个是后端启动时报“Access denied for user”九成是application.yml里的数据库密码和你的MySQL实际密码不一致改配置即可。第二个是小程序端控制台出现“request:fail url not in domain list”就是在开发阶段没有勾选“不校验合法域名”勾选后这个报错立刻消失。还有一个比较高发的数据库时区报错在数据库连接URL后加上serverTimezoneAsia/ShanghaiuseSSLfalse即可这一点在MySQL 8.0下几乎是必修课。6.2 线上部署的打法云服务器、域名和反向代理毕设答辩和成果演示如果用localhost档次会低一些。如果你手头有云服务器资源哪怕是最低配的2核2G机器都能把整套系统部署起来演示效果完全不一样。部署方案我推荐这么搭云服务器上安装Nginx作为反向代理服务器用来承载H5静态资源和小程序的前端静态文件后端SpringBoot工程打成jar包然后设定为开机自启的后台服务MySQL和Redis继续装在服务器上。如果你没有域名小程序真机测试会受限于合法域名校验所以多数情况下毕设的演示环境停留在开发者工具的模拟器上。条件允许的话可以注册一个域名并完成SSL证书配置再把小程序的request域名配置到小程序后台并在开发版中打开这样真机演示就很完整了。说一句真心话部署到云服务器最大的价值不是给别人看而是倒逼你自己把所有配置项彻底搞明白。你本地能跑通不代表环境迁移后还能跑通中间经历的每一个报错都是答辩场上能够自然讲出来的实战经验。我经常跟学生说主动在答辩中提一句“部署到云服务器的时候遇到过一个跨域问题通过配置CORS后解决了”这种真实经历比你背十页PPT都管用。6.3 答辩准备用一张图诠释整个闭环答辩PPT和演示环节是一条链路。在第一页需要让导师快速看懂整个项目的技术架构我建议你准备一张清晰的分层模型最上层微信小程序前端展示购物流程的界面跳转中间层SpringBoot后端列出核心模块用户模块、商品模块、购物车模块、订单模块、支付模块最底层的MySQL和Redis数据存储。这张图必须自己亲手画一遍不要直接盗用网图因为画图的过程就是你对整个项目架构的梳理过程。答辩中需要重点准备的四个回答方向我帮你提前列出来一是为什么选SpringBoot和微信小程序回答要落在“轻应用形态 企业级开发框架的经典组合”上二是数据库为什么这样设计回答要落在“订单快照 一对多拆分 状态机字段”这些关键词上三是如何解决并发扣库存问题回答要给出条件更新的实现方式和事务保障四是支付流程如何保证安全回答要涵盖签名、验签、回调幂等三个点。这几个问题答顺了整个答辩框架就立住了。7. 最后再分享几个让导师眼前一亮的可扩展方向项目跑通只是起点如果你还想往上加分我建议从下面几个方向里挑一个“轻量级”的扩展做。第一订单超时自动关闭。用户在待付款状态停留超过比如30分钟系统自动把订单状态改为已取消并回补库存。实现方式很简单用Spring的定时任务每分钟扫一次超时订单代码量二十行以内但讲出来的价值却是“解决了真实电商场景中的订单脏数据问题”非常讨巧。第二商品搜索功能。当前很多毕设商城只做分类浏览如果你在商品列表接口上增加一个模糊搜索关键词参数配合索引字段演示时用户只要输入“手机”就能筛出相关商品体验立刻上升一节。第三数据统计报表。如果你的毕业设计课题偏管理端方向可以再加一个简单的后台统计页面展示今日订单数、今日销售额、热销商品Top5数据从order_item表聚合查询而来只需一条SQL就能拉出来展示时能直接冲击视觉记忆。我在指导这一届学生做毕设的整个过程中感受最深的一点是毕业设计这东西本质上不是一个“做出一个多牛的系统”的考核而是一个“证明你具备独立完成一个完整项目能力”的考核。源码下载、看文档、抄教程都只是手段最终你要站在答辩台前清楚地说出每一行设计背后的理由。把这篇文章里从数据库设计到接口链路、从版本选型到答辩准备的逻辑都消化掉然后动手把项目从头到尾自己写进脑子里这个过程下来你不仅会拿到一个漂亮的毕设成果更会收获一套“拿到任何项目都能快速上手”的底气。这套底气比你答辩的分数更值钱。