简介在软件工程毕业设计中如何兼顾业务价值与技术深度是选题的关键。微信小程序凭借无需安装、触达用户成本低等特性成为连接消费者与服务者的轻量级载体而SSM框架作为Java后端经典组合通过Spring的依赖注入、SpringMVC的路由分发与MyBatis的持久化映射构建出清晰的三层架构。结合MySql关系型数据库可完整实现用户登录、商品管理、购物车、订单事务等核心功能。这类电商系统不仅覆盖常规增删改查还能通过事务注解保证下单流程的数据一致性是检验工程实践能力的典型场景。本文以大学助农扶贫微信小程序为例从技术选型、数据库设计到答辩策略系统拆解一套可落地的毕设方案帮助读者快速掌握微信小程序SSMMySql全栈开发的核心思路。 每年毕业季很多计算机相关专业的同学都在纠结毕业设计选题要么怕题目太简单撑不起论文要么怕技术太生僻自己啃不下来。如果你正好想做一个微信小程序方向的项目又希望后端能带点经典框架的含金量那这套“大学助农扶贫微信小程序”非常值得你参考。它是一套基于微信小程序 SSM MySql 的农产品电商类毕业设计项目交付物覆盖源码、数据库脚本、毕业论文、答辩PPT和演示视频基本就是“拿到就能跑、跑完能讲、讲完能答”的全流程方案。这个项目表面上看是一个普通的小程序商城但它把助农扶贫的业务场景和技术实现结合得很自然农户入驻发布农产品消费者浏览下单管理员在后台管理商品、订单和用户数据。从毕设评分角度来说它有明确的业务价值又有标准的 CRUD、登录鉴权、购物车、下单流程技术点和业务点都踩得比较稳。今天我把这套项目从选型到实现、从论文到答辩的完整思路拆给你哪怕你完全不打算用这套源码跟着走一遍也能把微信小程序和 SSM 开发摸透一大半。1. 项目整体设计与技术选型解析1.1 为什么偏偏是“微信小程序 SSM MySql”这套组合先说选型逻辑。很多同学在做毕业设计时容易犯一个错误一味追求“新”。今天看到 Vue3 火就上 Vue3明天听说微服务热门就硬拆几个服务结果做到最后框架都没跑通。毕业设计的核心目标不是炫技而是在有限时间和自身能力范围内完整地交付一个“需求成立、技术合理、工作量饱满”的项目。微信小程序 SSM MySql 恰好是这三个维度的黄金交汇点。从用户侧看微信小程序是目前触达普通用户成本最低的载体不需要下载 App扫一扫就能用天然适合助农扶贫这种需要降低使用门槛的场景。消费者在微信里完成浏览、下单、支付入口引导农户端和管理员端则通过 Web 后台管理一前一后两个端既有区分度又有联动性。从开发侧看SSM 是 Java 后端经典的“教科书组合”。Spring 负责对象管理和事务、SpringMVC 负责接口路由、MyBatis 负责数据库操作每一层都各司其职。这套框架已经沉淀了十几年网上资料多、问题排查容易更重要的是面试官对它的提问点非常固定——IOC、AOP、依赖注入、Mapper 代理、事务传播行为你只要在毕业设计里真的用到了答辩的时候就能讲出实际案例而不是背概念。从数据侧看MySql 是开源数据库里最主流的选择5.7 和 8.0 都非常成熟网上有大量安装配置教程和 SQL 避坑经验。对毕设而言MySql 完全够用而且 Navicat 或 Workbench 可视化导入导出、建表都很方便能省下不少折腾时间。我的建议是除非你有非常明确的技术倾向否则不要轻易换掉这套组合。换成 Spring Boot 当然也可以但 SSM 让你对配置细节的理解更深答辩时反而更有话可讲。1.2 功能模块是怎么拆出来的这套项目的功能设计遵循了典型的“用户端 管理端”双端结构。用户端面向普通消费者管理端面向平台运营人员两侧数据通过同一个后端接口打通。功能拆得好不好直接决定后期论文目录和答辩讲稿是否好写。我把核心功能整理成了一张表做毕设时你可以直接拿这张表去对应自己的模块划分端模块名称核心功能点说明微信小程序端登录模块微信授权登录、openid 绑定不需要自己搞注册流程微信小程序端首页与分类轮播图、分类导航、热销推荐涉及商品分类表的设计微信小程序端商品模块商品列表、商品详情、搜索列表支持分页加载微信小程序端购物车模块加入购物车、修改数量、删除本地存储与后端同步微信小程序端订单模块下单、订单列表、取消订单下单是核心事务流程微信小程序端个人中心收货地址管理、我的订单入口可配合单选选默认地址管理后台端商品管理商品上架、下架、编辑上传图片、填写价格库存管理后台端订单管理订单列表、发货、查看详情后端多表关联查询集中地管理后台端用户管理用户列表、禁用启用体现后台管理价值管理后台端数据统计商品数、订单数、销售金额可以用简单的聚合函数完成这个功能清单看起来并不复杂但已经覆盖了“登录、增删改查、多表关联、事务、文件上传、权限控制”这些毕业设计考核的高频技术点。助农扶贫的“扶贫”属性主要体现在商品分类上比如设置“扶贫专区”或者“农户直供”标签这样在论文里就能很自然地写出项目的应用价值。1.3 数据库表设计的基本思路数据库设计是毕业设计里最容易被扣分、也最容易被忽视的地方。很多同学一开始图省事把所有字段塞进一张表结果写到订单功能的时候发现逻辑怎么都理不顺。这套项目的表结构走的是标准电商模型我按核心程度排个序用户表user是最基础的一张表核心字段包括 id、openid、昵称、头像、手机号、注册时间。openid 是微信用户的唯一标识小程序端通过 wx.login 获取临时 code再通过后端调用微信接口换取 openid用 openid 来判断用户是否已存在而不是让用户自己输入账号密码。商品表product和分类表category是商品模块的两张核心表。商品表字段有 id、分类 id、商品名称、主图、价格、库存、销量、描述、状态上架/下架、创建时间。分类表就是 id 和分类名称商品通过 category_id 关联分类一对多关系。购物车表cart用于记录用户加入购物车的操作字段有 id、user_id、product_id、数量、加入时间。这里要注意购物车应该用“用户 商品”作为去重维度如果同一商品重复加入应该直接更新数量而不是插入新记录。订单模块涉及两张表订单表orders和订单明细表order_item。订单表存的是订单的全局信息比如订单编号、用户 id、总金额、状态待支付、待发货、已发货、已完成、已取消、收货人、收货地址、下单时间。订单明细表存的是订单里的每一件商品比如商品 id、商品名称、商品快照价格、数量。为什么要拆两张表因为一个订单可能包含多个商品如果所有信息都塞在订单表里查询和统计会变得非常别扭。拆成主表和子表也正好用上“一对多”这个重要的数据库概念。地址表address相对独立字段有 id、用户 id、收货人、手机号、省市区、详细地址、是否默认。这里有一个值得在答辩时讲的细节默认地址的设计。我的做法是在用户表里不存默认地址 id而是在地址表里通过一个 is_default 字段标记但要注意同一用户只能有一条默认地址这在新增和修改时有几个边界情况需要处理好。数据库表设计完小程序的首页轮播图、公告、限时活动等功能可以再增加 banner 表和 notice 表但非必需。从毕设的工作量来看六到八张核心表是最合适的规模既能展示设计能力又不会把自己框死在复杂的表关系里。2. 核心功能实现与实操要点2.1 小程序端登录wx.login 与 openid 绑定小程序端的登录是整个项目的地基。后面所有涉及用户身份的操作比如加入购物车、下单、查看订单都需要先知道“当前用户是谁”。微信小程序的登录逻辑和传统用户名密码登录完全不同它依赖微信的开放能力。简单的流程是这样的小程序端调用 wx.login 获取一个临时 code这个 code 有效期只有五分钟把它通过 request 请求传到后端。后端拿着这个 code 去请求微信的接口通常是通过 HttpClient 调用换取 openid 和 session_key。openid 是用户在当前小程序下的唯一 ID后端的逻辑是先根据 openid 查用户表如果查不到就创建一条新用户记录如果查得到就直接登录成功。之后后端生成一个自定义的登录态比如 token返回给小程序端小程序端把 token 存在 storage 里后续每次请求在 header 里带上。实际开发中有一个容易踩的坑微信接口的调用地址是 https://api.weixin.qq.com/sns/jscode2session这个请求必须要在后端发起不能在小程序端直接请求因为涉及到 appSecret 的安全问题。另外获取 openid 的接口返回的是 JSON里面除了 openid 还有 session_keysession_key 用来解密手机号等敏感信息毕设阶段用到的不多但论文里可以提一句。2.2 request 请求封装与接口对接规范小程序端和后端交互靠的是 wx.request 这个 API。但是如果你每个页面都裸写 wx.request代码会非常冗余而且后期想统一处理 token 过期、错误提示都很麻烦。我的习惯是在 utils 里封装一个 request.js 文件用 Promise 包裹 wx.request让它变成可 await 调用。封装的核心点有几个第一baseURL 统一定义前端所有请求只用写相对路径方便切换联调和线上环境。第二请求拦截器自动从 storage 拿 token 拼到 header 里。第三响应拦截器统一判断后端返回的状态码 status如果 status 是 401 表示登录过期就跳转到登录页重新授权如果 status 是其他错误码就用 wx.showToast 弹出错误信息。这里涉及一个容易混淆的概念HTTP 状态码和业务状态码是两回事。后端接口即使业务失败也可能返回 HTTP 200只不过 JSON body 里的 status 是 500 或 403。前端封装时要以业务状态码为准不要判断 res.statusCode 等于 200 就认为成功。我在给不少同学 review 代码时都发现过这个问题业务明明报错了前端还在继续渲染空数据。另外后台接口如果跑在本地电脑上小程序端是无法直接通过 localhost 访问的。因为小程序的请求是在微信客户端里发起的不是从你电脑发起的。你需要保证后端服务和手机在同一个局域网内然后在 request 的 baseURL 里填你电脑的局域网 IP比如 http://192.168.1.100:8080。开发者工具里还要勾选“不校验合法域名”选项。真机测试时同样要在手机和电脑连同一个 Wi-Fi 的前提下才能调通。2.3 首页与商品列表的动态渲染小程序的首页是用户进门的第一印象也是项目演示时最容易“出效果”的部分。首页常见的结构是顶部搜索框 banner 轮播 分类导航 商品瀑布流或列表。这几个模块的数据来源不一样但可以通过一个聚合接口一次性返回给前端减少请求次数。banner 轮播使用小程序自带的 swiper 组件只要把后端返回的 banner 图片 URL 数组填入即可。这里需要注意图片域名的问题如果图片是外链一定要把域名配置到小程序后台的 downloadFile 合法域名里正式上线必须配开发调试时可以在开发者工具里勾选不校验域名。分类导航和商品列表相对简单用 scroll-view 做横向滚动商品列表用 wx:for 循环渲染。商品列表的分页加载是一个高频考点。小程序端的核心交互是 onReachBottom 触底加载下一页通过 data 里的 pageNum 和 pageSize 参数控制。前端在请求时带上当前页码后端 SQL 里用 LIMIT 实现分页返回同时返回总条数或是否有下一页。这里要注意每次请求新一页的数据应该是追加到 list 后面而不是替换掉整个数组在请求过程中要加一个加载锁防止用户快速滑动时触发重复请求。2.4 购物车与下单流程的实现细节购物车和下单是电商项目的核心流水线也是论文里能写“事务”的地方。购物车的实现思路是把数据存到后端 cart 表前端展示时调接口获取当前用户的购物车列表。用户点击“加入购物车”时前端传入 productId 和 quantity后端先查这个用户是否已经加过该商品如果已存在就做数量累加否则新增一条记录。下单流程则是典型的数据库事务场景。用户从购物车勾选商品进入确认订单页确认收货地址后点击提交订单。后端在保存订单时需要同时完成三件事往 orders 表插入主表记录、往 order_item 表插入明细、清空购物车对应记录。这三步操作必须要么全部成功、要么全部失败不能出现订单生成了但明细没写进去的情况。在 SSM 中这是通过在 Service 方法上加 Transactional 注解实现的当方法内任何一步抛出异常时整个事务回滚。下单时还有一个容易忽略的细节库存扣减。用户在商品详情页看到的库存和实际下单时的库存可能不一致因为可能有多个人同时在买。常规做法是在生成订单时对商品库存做条件更新UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}。如果更新影响行数为 0说明库存不足直接抛出业务异常。这个写法虽然不能完全解决高并发下的超卖但毕业设计答辩的时候你能说出“库存扣减需要做条件校验”这句话就已经比绝大多数同学强了。支付环节个人开发者的微信支付接入比较麻烦需要企业资质和商户号。大部分毕设项目都以“模拟支付”代替即点击“去支付”按钮后直接在前端弹窗提示“模拟支付成功”然后调用后端接口把订单状态改为待发货。这个方法在论文里要写清楚说明“因微信支付需要企业资质系统采用模拟支付流程核心逻辑与真实支付一致”。2.5 SSM 后端的 Controller - Service - Mapper 三层结构SSM 项目的后端代码组织是一门基本功也是答辩时老师爱看的部分。这个项目采用的是经典的 Controller-Service-Mapper 三层架构。Controller 层负责接收前端请求、校验参数的合法性然后调用 Service 层最后把结果封装成统一的 JSON 格式返回给前端。这里我建议定义一个 Result 类包含 code、message、data 三个字段所有接口都返回这个结构。前端拿到之后先判断 code 是否为 200再取 data 渲染页面。这样做的好处是接口风格统一前端封装 request 时可以集中判断业务状态码。Service 层是业务逻辑的核心负责处理“用户加入购物车时商品是否存在、下单时库存是否充足、订单状态流转是否合法”这类规则。这一层应该抛开 Servlet 和 MyBatis 的细节只关注业务流程。Service 层的方法命名也很重要尽量用业务语言而不是技术语言比如 addProduct、createOrder、cancelOrder答辩时一眼就能看出你的业务边界。Mapper 层负责数据库操作。在 SSM 项目中MyBatis 的 Mapper 通过接口定义方法、通过 XML 或注解写 SQL。复杂 SQL 建议放在 XML 里因为可读性好、方便拼接动态条件。举个例子商品列表搜索功能前端可能传商品名关键字和分类 id这两个条件是可选的这时在 XML 里使用 和 标签做动态 SQL既优雅又安全还能有效防止 SQL 注入。2.6 “单选框”在小程序端的典型应用场景搜索热词里有一条“微信小程序单选框”正好在这套项目里有非常典型的应用场景——收货地址选择和支付方式选择。确认订单页中用户选择收货地址时通常会给用户展示已有的地址列表每条地址前面有一个 radio 单选框选中后高亮并显示“默认”标签。微信小程序里 radio 组件通常搭配 radio-group 使用radio-group 的 bindchange 事件会返回当前选中的 value。我的做法是把每条地址的 id 作为 radio 的 value选中后就把这个地址对象回填到订单确认页的地址栏。支付方式的单选框更简单一般是“微信支付”和“模拟支付”两个选项。核心交互点在于用户点击“提交订单”后必须先判断地址是否已选择、支付方式是否已选择。前端做这种表单校验时不要只用 wx.showToast 盲提示最好在 radio-group 下面有一行提示文案实时联动提升演示时的完成度。还有一个容易被忽略的单选场景商品详情的规格选择。比如扶贫茶叶有“250g 装”和“500g 装”两种规格用 radio 做规格选择比 picker 更直观。实现方式就是把同规格的商品做成一个 sku 列表用户选中的 sku id 决定了展示的价格和库存同时把 skuId 传给后端用于下单。如果毕设里有这个功能演示效果会好很多因为看起来更像一个真实商城。3. 毕业论文、答辩PPT与演示视频的准备策略3.1 毕业论文的目录结构与写作套路毕业论文是毕业设计评分的大头很多同学代码都跑起来了论文却写得像流水账。这套项目的论文目录可以从下面这个结构去规划这是大多数软件工程类毕设论文可以通用的框架第一章是绪论写研究背景、国内外研究现状、研究内容和意义。这一章不用写太长但要写出“助农扶贫需要信息化工具”这个业务切入点然后用两到三段概括目前已有的电商平台存在的问题最后引出本系统要解决什么。第二章是相关技术介绍重点讲微信小程序、SSM 框架、MySql 数据库。这部分看起来是“凑字数”但其实是有技巧的你不仅要写每个技术是什么最好再写一点“为什么本项目选它”比如“微信小程序无需安装、触达用户成本低有利于扶贫农产品推广”这样教授会觉得你是在为项目做技术选型而不是在抄百科。第三章是系统分析包括可行性分析、需求分析、功能需求分析、数据流图。需求分析建议用表格列出每个功能模块的详细描述再配用例图。用例图不要画得特别复杂能说明用户、商家、管理员三类角色分别能用哪些功能就够了。第四章是系统设计包括总体架构设计、功能模块设计、数据库设计。数据库设计要给出具体的表结构字段表这是论文里信息量比较大的部分评委老师通常也会重点翻看这一章看看你的表设计是否规范、字段命名是否清晰、主外键关系是否明确。第五章是系统实现按模块去写每个模块配上运行截图和关键代码片段。记住一个原则截图要截“带数据”的界面不要截空表。关键代码不要大面积贴选择 3 到 5 段核心代码就好比如 wx.login 换取 openid 的代码、动态 SQL、下单时的事务管理代码。第六章是系统测试写测试环境、测试用例和方法、测试结果。测试用例表是这一章最有说服力的内容比如“输入一个不存在的商品 id点击加入购物车预期返回商品不存在提示实际结果符合预期”类似这种。最后再写一个测试结论。3.2 答辩 PPT 怎么设计才能把项目讲清楚答辩 PPT 的页数控制在 15 到 20 页之间讲的时间通常只有 5 到 10 分钟所以原则是“少放代码多放图和流程”。我建议按这个顺序组织 PPT项目背景与意义2 页、技术选型2 页、功能模块框架图或思维导图2 页、数据库设计2 页、系统核心功能截图4 到 5 页、系统测试结果1 页、总结与展望1 页。PPT 里有两样东西是加分项第一功能架构图。你不需要画非常精细的 UML 图用一张简单的分层图展示“小程序端、后端、数据库”三者之间的关系再把每个端底下的功能点写出来老师一看就明白项目全貌。第二数据库关系图。用 Navicat 或 PowerDesigner 导出一张 ER 图PPT 里放上去讲表之间怎么关联比罗列字段强得多。答辩时老师最爱问的问题我提前给你列几个“为什么不用 Spring Boot 而用 SSM”“openid 和 session_key 有什么区别”“下单流程中怎么保证数据一致性”“如果前端传过来的商品价格被人篡改了怎么办”每一个问题在项目里其实都有对应的答案答辩前一定要把这些问题对着代码过一遍。比如价格篡改的问题后端下单时不应该信任前端传过来的 price 字段而是根据商品 id 从数据库重新查询价格来计算金额这个点讲出来老师会觉得你对安全问题有思考。3.3 演示视频的录制范围与脚本设计演示视频时长控制在 10 分钟以内是毕业设计材料里给评审老师留下第一印象的部分。不需要花哨的剪辑和配音但需要“流畅、完整、标注清晰”。视频录制时建议按下面的脚本走先展示系统登录和首页说明用户如何通过微信授权进入系统再演示修改个人信息、添加收货地址的过程然后演示浏览商品、查看商品详情、搜索商品接着是最核心的部分把商品加入购物车、从购物车下单、选择地址、模拟支付、查看订单详情这一整套流程从点击到完成最好一气呵成中间不要有长时间停顿最后切到管理后台演示管理员登录、商品上下架、订单发货提到一句“管理端采用 Web 页面后端接口与小程序端共用”。录制工具有很多电脑端 Win 自带的 xbox game bar、OBS、EV 录屏都可以。需要注意的一点是在录之前把开发者工具的 Console 面板收起来不要录进去无关报错。如果带配音讲解建议提前写一段讲解词哪怕照着念比临场发挥更稳。视频导出为 MP4 格式分辨率和码率不用太高能看清界面文字就行。4. 从环境搭建到答辩通关常见问题与排查技巧4.1 MySql 安装、连接与数据初始化避坑MySql 是这套项目里环境搭建最容易出问题的环节我见过大量同学卡在这一步。新手安装 MySql 时最容易踩的坑是安装完成后本地能连但项目连不上。这个问题 90% 是连接配置不对。SSM 项目一般在 jdbc.properties 文件里配置数据库连接需要注意四个核心参数数据库地址、用户名、密码、驱动类。MySql 8.0 的驱动类是 com.mysql.cj.jdbc.DriverMySql 5.7 则是 com.mysql.jdbc.Driver这两个不能混用。同时MySql 8.0 的连接 URL 还需要加上时区参数比如 useSSLfalseserverTimezoneAsia/Shanghai否则会报时区相关的错误。如果你本机装的是 MySql 8.0但网上找的教程默认写的是 5.7 的配置就会一头雾水地栽进去。数据库导入脚本时要注意 SQL 文件的编码。很多源码附带的 sql 文件是 UTF-8 编码但如果你用 Navicat 默认连接使用的字符集是 utf8mb4导入时反而不太会出问题。真正容易出问题的是 Windows 命令行导入如果字符集不一致导入后中文全是乱码。建议用 Navicat 直接“运行 SQL 文件”这种方式并且把文件的字符集选成 UTF-8。4.2 小程序端真机调试与白屏问题排查小程序开发中有一个非常经典的问题开发者工具里一切正常一到真机预览就白屏或请求失败。这里面的原因通常集中在三个地方。第一网络和域名问题。真机上无法像开发者工具那样勾选“不校验合法域名”所以如果你在 request 的 baseURL 里填的是局域网 IP真机上预览时微信会默认拦截。临时方案是在“微信开发者工具 - 详情 - 本地设置”里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”并把项目上传为体验版真机上打开体验版时也开启“开发调试”。这种场景下能调通但正式上线一定要配置 HTTPS 域名。第二渲染层 JS 报错。真机白屏八成是 JS 执行异常导致页面渲染不出来而开发者工具默认不会拦截所有错误。排查方法是在微信开发者工具里点击“真机调试”按钮它会打开一个远程调试的控制台真机上发生的 console 报错都会实时打出来。看到报错后再定位代码比盲猜快得多。第三图片不显示。如果数据库里存的图片 URL 是 http://localhost 开头开发者工具里能显示是因为它就运行在你本机真机上这个地址指向的是手机自己当然访问不到。所以根因是数据里的图片地址不能写死 localhost要么存相对路径后由后端拼接完整地址要么存完整的外链 URL。顺便提一句社区里经常会有人问“微信小程序可以使用天地图画地图组件吗”这个在助农项目里如果要做农场地点的地图展示确实可以用 web-view 加载天地图 Web API 来实现。不过毕设的核心功能不是地图能把这个作为扩展点来展望就可以了没必要卷进地图 SDK 的接入坑里。4.3 SSM 框架重点难点与答辩高频提问SSM 框架对很多同学来说难点不是写代码而是理解“代码是怎么跑起来的”。我给一个最快的理解路径用户在浏览器或小程序端发起一个 HTTP 请求请求先到达 SpringMVC 的 DispatcherServlet它根据 URL 找到对应的 Controller 方法Controller 调用 Service 拿到业务结果Service 内部通过 MyBatis 的 Mapper 接口操作数据库Mapper 的 SQL 写在 XML 里由 MyBatis 在启动时解析并生成代理对象。整个过程就是“请求进、数据出”中间每一个环节都由 Spring 容器管理。答辩时如果老师问“SSM 的分层有什么优势”不要只说“解耦”要举项目里的例子。比如订单业务Controller 层只负责接收参数、回传结果Service 层处理下单逻辑Mapper 层简化数据库访问改 SQL 时只需要动 XML不需要动 Java 代码。这个例子能体现你真的理解分层的好处。如果老师问“Spring 的核心是什么”重点讲 IOC控制反转和 AOP面向切面编程。IOC 就是对象创建和依赖管理交给 Spring 容器AOP 在项目里的典型应用是事务管理Transactional 注解本质就是 AOP 在方法前后织入了事务开启、提交、回滚的逻辑。能用自己的项目把这个讲清楚比复述教科书定义更容易拿高分。4.4 时间规划建议两个月完成毕设的节奏最后再聊一个容易被忽略但非常现实的问题时间规划。很多同学拿到源码后第一周在看代码第二周在调环境第三周发现论文没写第四周开始通宵。如果你还有两个月的时间准备毕设我建议你这样分配前两周跑通项目理解代码结构把数据库脚本导入成功、前后端跑通、能录一段完整的功能演示第三到四周开始改代码不用大改改几个关键点就行比如增加一个商品分类、给订单模块加一个筛选状态这个过程会让你对代码的理解上一个台阶第五到六周集中写论文论文的骨架照上面的目录搭每天写一到两章配上截图第七周到第八周准备答辩 PPT、演示视频和模拟答辩把高频问题背熟。要特别提醒的是不要做“拿来主义”哪怕老师允许你用现成源码你也至少要能独立讲清楚每个模块的流程和关键代码。答辩现场最尴尬的瞬间就是老师说“请讲一下下单这个功能你怎么实现的”你盯着屏幕一句话说不出来。反过来如果你真的把一个模块的代码读懂了、改过几行看着自己跑起来的项目那种底气和安全感是很真实的。我个人这些年看过很多毕业设计一个深切的体会是评价一个毕设项目好不好不完全在于技术多高深而在于你对自己做的东西理解有多深。这套助农扶贫微信小程序的架构很简单、代码也不复杂但只要你能把登录、购物车、下单、后台管理这条主线上的每一个决策讲清楚能说出为什么这么设计、遇到问题怎么排查它就是一个能拿良好甚至优秀的毕业设计。最后分享一个小技巧答辩前把项目从零到一跑一遍从启动 MySql、导入数据、启动后端、打开小程序、完成一单交易每一步都练熟你会发现真正到了台上紧张感会少很多。本文还有配套的精品资源点击获取