去年这时候我正抱着电脑窝在图书馆面前摊着一沓答辩要求选题表上被导师划掉了三个太简单没深度的题目最后才定了这个基于微信小程序的优购电商的设计与实现后端框架指定SSM。当时心里多少有点犯嘀咕——SSM不是过时了吗网上全是Spring Boot加微服务的教程我这套配置繁琐到让人头疼的框架做出来还有价值吗但现在回过头看我得说句实在话SSM加原生小程序这个组合恰恰是毕业设计里性价比最高、最容易做出完整度的选择。这篇文章我不打算写成教程合集而是想以一个刚走完全流程的过来人身份把整个项目的选型逻辑、前后端设计、开发中踩过的坑、以及论文和答辩的注意事项一次性讲透。不管你是正在选题还是已经写到半路我相信总有几段能对你有用。1. 选型的安全性逻辑为什么是微信小程序凭什么用SSM1.1 毕业设计选型的第一原则能讲清楚比够新鲜更重要很多同学选毕设题目时有个误区觉得技术越新越容易拿高分。我一开始也试过Spring Boot加Vue3加Redis缓存那一套时髦组合结果被导师一句话点醒你选的技术我要都能看懂你自己才讲得明白。这句话后来我越想越觉得对。毕业设计考察的不是你会不会追热点而是你有没有完整地走完一个项目的生命周期能不能把每个技术决策的前因后果说清楚。微信小程序作为优购电商的载体有几个无可替代的优势。第一用户不用下载App扫个码或者在微信里搜索就能打开转化路径短这个特性天然契合电商的轻量购物场景。第二小程序的技术栈是WXML、WXSS、JavaScript学完前端三件套的同学几乎零成本上手和我后面要写的毕业论文里前端技术介绍这一章也能无缝衔接。第三微信生态自带分享、支付、订阅消息能力一个电商系统该有的闭环功能小程序在底层都给你提供好了接口。SSM则正好卡在足够经典和足够深入之间。Spring管对象容器SpringMVC管请求分发MyBatis管数据库访问三层各司其职结构清晰到可以画在论文里当架构图。更重要的是SSM要求你手动配置各种XML和注解这个麻烦的过程本身就是论文里系统详细设计章节的素材。反观Spring Boot自动配置把什么都包好了论文里你除了写引入依赖几乎无话可说。1.2 原生小程序与uniapp的真实取舍选型时我在原生小程序和uniapp之间徘徊过一阵。uniapp能一套代码编译到微信、支付宝、H5多端听起来很香但它有一个隐藏的麻烦编译中间层带来的是排查问题时的信息损耗。你写的是Vue语法编译成小程序后却要按小程序的生命周期去调试出问题了经常不知道是代码的问题还是编译的问题。毕设的周期有限多一个不确定变量就多一份翻车风险所以最后我选了原生小程序。原生小程序的学习曲线其实非常友好。它的页面结构类似于一个轻量级的Vue单文件组件每个页面由四个文件组成.wxml结构、.wxss样式、.js逻辑、.json配置。如果你之前写过HTML加CSS加JavaScript上手第一天就能写出像样的页面。微信开发者工具还自带模拟器和真机调试对比浏览器里的F12它能直接模拟不同机型的运行效果这对后面处理顶部导航栏适配问题帮助极大。1.3 系统的整体架构与技术分工优购电商的整体架构分三个端微信小程序客户端、SSM后端、MySQL数据库。小程序通过wx.request发起HTTP请求访问后端后端部署在Tomcat上用SpringMVC对外提供JSON格式的REST接口MyBatis负责SQL操作Redis用来存储登录token和缓存热门商品数据这个属于加分项后面细说。用户从点开小程序到完成购买完整的请求路径是这样的小程序页面触发事件 → 调用wx.request→ 请求到达SpringMVC的Controller → Controller调用Service层处理业务 → Service调用Mapper接口 → Mapper通过MyBatis执行SQL → 数据逐层返回 → 小程序setData更新页面渲染。这个链路我会原封不动画进论文的系统架构图里答辩时对着图讲逻辑非常顺畅。2. 小程序端核心模块从首页到订单的闭环实现2.1 首页、分类页与基础组件搭建首页是电商的脸面我的优购小程序首页布局从上到下依次是搜索框、轮播图、分类金刚区、商品推荐流。轮播图直接用微信自带的swiper组件绑定一个图片数组设置autoplay和circular属性即可三行代码的事。金刚区用flex布局做宫格每个格子绑定一个分类ID点击跳转到对应的商品列表页。这里有个新手必踩的坑图片资源千万别一股脑塞进小程序包里。小程序的代码包有明确的大小限制主包超过2MB就编不过去本地图片一多必然超限。正确做法是把所有图片上传到服务器或云存储数据库里只存图片URL页面通过image组件加载网络图片。这个操作也是热搜词里电商图片优化的第一层含义——不优化连包都发布不了。分类页我做了左侧一级分类、右侧商品列表的经典布局。左侧是scroll-view纵向滚动列表右侧是根据当前分类ID请求到的商品卡片流。左右联动的逻辑是点击左侧分类项时更新当前分类ID重新请求右侧数据并让右侧scroll-view回到顶部。这一块虽然工作量不大但在论文系统实现章节里能配上两张截图讲得头头是道。2.2 商品列表的分页与加载更多商品列表的无限滚动可能是整个小程序端最容易被问细节的地方。微信小程序的页面有onReachBottom这个生命周期事件页面滚动到底部时自动触发。我做分页的思路是维护三个状态变量page当前页码、size每页条数、hasMore是否还有下一页。首次进入页面时请求page1的数据每次滚动到底部先判断hasMore是否为真为真则page加一把新返回的数组concat到现有列表后面如果某次请求返回的条数小于size说明已经到最后一页把hasMore置为false。这套逻辑本身不难难的是防止重复请求。用户快速滑动时onReachBottom可能在短时间内连续触发多次如果不加锁同一页数据会被请求好几遍列表里出现重复商品。我的解决方法是加一个isLoading标志位onReachBottom() { if (this.data.hasMore !this.data.isLoading) { this.setData({ isLoading: true }); this.loadNextPage(); } } async loadNextPage() { try { const res await request.get(/api/goods/list, { page: this.data.page, size: this.data.size, categoryId: this.data.categoryId }); this.setData({ goodsList: this.data.goodsList.concat(res.data.list), page: this.data.page 1, hasMore: res.data.hasMore }); } finally { this.setData({ isLoading: false }); } }要特别注意的是isLoading的复位必须在finally里做而不是在success回调里。万一网络异常走了fail分支锁没解开后续所有滚动加载都会失效页面就卡死在底部了。这个细节我在论文的功能测试表里专门写了一个用例属于边界条件测试的范畴。2.3 登录体系wx.login、静默登录与用户信息授权电商必须要有用户体系不然购物车和订单无从谈起。我选择以微信登录为核心辅以手机号绑定。整个流程不复杂但对新手来说坑点密集小程序端先用wx.login()获取一个临时登录凭证code这个code的有效期只有五分钟而且只能用一次。拿到code后调用后端接口/api/user/login后端拿着code去请求微信的jscode2session接口换取用户的openid和session_key。openid是用户在某个小程序下的唯一标识用它作为用户表的主键关联字段。后端拿着openid去数据库查查不到就自动注册一个新用户然后生成一个UUID作为自定义登录态token存Redis并设置七天过期最后把token返回给小程序。小程序端收到token后存入wx.setStorageSync(token, ...)后续所有需要登录态的请求都在请求头里携带这个token。这套机制相当于把微信的身份认证翻译成了自己系统的会话管理不依赖Cookie和Session天然适配小程序的Http请求模型。// 小程序端登录 wx.login({ success: res { wx.request({ url: https://api.ugou.com/api/user/login, data: { code: res.code }, success: res { wx.setStorageSync(token, res.data.data.token); // 登录成功后刷新购物车角标 this.updateCartBadge(); } }); } });登录环节有一个特别容易让人抓狂的报错url not in domain list。小程序对wx.request的域名有严格限制开发时可以在开发者工具里勾选不校验合法域名临时绕过但真机预览和体验版必须到微信公众平台把后端接口域名配置进request合法域名。我第一次在手机上打开体验版时所有请求全部失败排查了半天才发现是域名白名单的问题这个坑建议提前避掉。2.4 购物车、订单与模拟支付购物车是本地与远端结合的数据。我的实现是未登录用户把购物车存在本地storage登录后把本地购物车提交到后端执行合并以后端数据为准。合并逻辑是拿本地购物车列表逐条调后端接口同一商品的购买数量累加。这一块在论文里可以作为系统特色功能写一小节显得你有业务思考。订单流程完整走下来是购物车勾选商品 → 点击结算 → 填写或选择收货地址 → 提交订单生成待付款订单 → 支付 → 商家发货 → 用户确认收货 → 订单完成。关于支付我必须提醒一句个人主体的小程序无法开通微信支付商户号所以毕设中的支付环节普遍做成模拟支付。我实现的方案是订单生成后弹出一个支付确认框点击确认支付直接把订单状态从待付款改成已支付。后端用orderStatus字段控制状态流转0待付款、1待发货、2待收货、3已完成、4已取消。每个状态变更都会写入订单日志表这个日志表在论文测试章节非常有用我可以展示一条订单从创建到完成的完整状态变迁记录配一张数据库截图证明业务闭环是通的。3. SSM后端设计数据库建模、接口分层与核心业务逻辑3.1 数据库表设计八张表覆盖完整电商闭环优购电商的数据库我设计了八张表用户表user、商品表goods、商品分类表category、购物车表cart、订单表orders、订单明细表order_item、收货地址表address、轮播图表banner。这个表规模对毕设来说不算少但也完全可控。以商品表为例设计时要注意几个实用细节。价格字段必须用decimal(10,2)不能用float否则浮点运算会出现0.1加0.2不等于0.3这类精度问题。详情图我用一个text字段存逗号分隔的URL列表虽然不满足严格的数据库第一范式但在电商这种读多写少的场景下反而比建一张子表更高效。库存字段stock要配合乐观锁使用这个后面展开。CREATE TABLE goods ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL COMMENT 分类ID, name varchar(200) NOT NULL COMMENT 商品名称, subtitle varchar(200) DEFAULT NULL COMMENT 副标题, main_image varchar(500) DEFAULT NULL COMMENT 主图URL, detail_images text COMMENT 详情图URL逗号分隔, price decimal(10,2) NOT NULL COMMENT 售价, stock int(11) NOT NULL COMMENT 库存, sales int(11) DEFAULT 0 COMMENT 销量, status tinyint(4) DEFAULT 1 COMMENT 1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category_status (category_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里我还做了一点小心思给category_id和status建了联合索引因为商品列表最常见的查询条件就是查某个分类下已上架的商品联合索引能让这个查询走索引避免全表扫描。答辩时老师如果问你的SQL性能怎么优化你把这个索引设计拿出来讲是一个很扎实的加分点。3.2 经典三层架构与SSM常用注解后端代码严格按照Controller → Service → Mapper三层分层这也是SSM框架的核心组织方式。Controller层用RestController和RequestMapping声明接口地址用RequestBody接收JSON请求体、RequestParam接收URL参数、PathVariable接收路径参数。Service层用Service注册为Spring容器中的Bean业务逻辑都写在这里。Mapper层是接口加XML接口方法上用Param注解绑定SQL参数名。热搜里ssm常用注解之所以是高频词是因为这几个注解的搭配确实容易懵。我总结一套入门模板Controller里Autowired注入ServiceService里Autowired注入Mapper链路就通了。Autowired是按类型注入的如果你在同一个接口下有多个实现类可以用Qualifier指定具体的Bean名称不过毕设里一个Service接口对应一个实现类用不到那么复杂。商品分页查询的MyBatis XML写法值得贴一下因为if动态SQL和LIMIT分页是MyBatis最常用的能力select idselectGoodsPage resultTypecom.ugou.entity.Goods SELECT * FROM goods WHERE status 1 if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if ORDER BY choose when testsort salessales DESC/when otherwiseid DESC/otherwise /choose LIMIT #{offset}, #{size} /select搜索关键词用LIKE CONCAT(%, #{keyword}, %)而不是直接%${keyword}%前者是预编译的能防止SQL注入后者是字符串拼接有注入风险。这个细节放在论文里能体现你的安全意识。3.3 登录校验拦截器加Token方案用户登录后生成token存Redis这一步我在小程序端已经提过。后端的实现重点在拦截器。我写了一个LoginInterceptor实现HandlerInterceptor接口在preHandle方法里从请求头取出token去Redis查用户查不到就返回401状态码和未登录的JSON。这个拦截器在SpringMVC配置里要注册并配置excludePathPatterns排除掉不需要登录的路径包括登录注册接口、商品列表接口、商品详情接口、轮播图接口。这个排除路径的配置特别容易出问题。我第一次写完拦截器后前端所有请求都被拦了连登录接口自己都进不去前端一直报401。排查了半天才发现是excludePathPatterns里写错了路径格式/api/user/login写成了/api/user/**把整个用户模块都放行了而其他模块又全都拦了。这种问题属于配置类问题不像业务Bug有明确的现象很难定位我的建议是把拦截器配置单独写一个类并且启动时打印注册的拦截路径列表方便核对。3.4 订单创建与库存防超卖订单创建是后端最核心的业务逻辑。基本流程是接收订单参数商品ID列表、数量、收货地址ID→ 校验商品存在且已上架 → 检查库存 → 扣减库存 → 创建订单和订单明细 → 返回订单号。扣减库存这里我用了乐观锁方案核心就是一条带条件的SQLUPDATE goods SET stock stock - 1 WHERE id #{goodsId} AND stock 0受影响行数为0说明库存不足这次扣减失败订单也就不能创建。为什么不用先SELECT stock再UPDATE因为在高并发场景下两个请求同时查到库存还有1都认为自己能买然后各自扣减最终库存变成-1就是超卖。乐观锁把检查库存和扣减库存合并成一条原子SQL天然解决了这个并发问题。这条SQL虽然简单但它在答辩时的分量很重因为它是少数几个能讲清楚并发问题的真实业务场景。3.5 Redis缓存热点商品数据如果想让系统的技术含量再高一层可以引入Redis做商品缓存。我在商品详情接口上做了一层Cache Aside缓存用户第一次请求某个商品详情时先查Redis没有则查数据库然后把结果写入Redis并设置半小时过期后续请求直接命中Redis减轻数据库压力。商品更新时会删除对应缓存保证下次查询拿到最新数据。但注意缓存引入后会带来数据一致性问题。比如管理员修改了商品价格如果缓存没删用户端还是会看到旧价格。我的处理方案是所有写操作执行成功后同步删除Redis中的对应键。这个思路在论文里可以写进系统优化或未来展望表明你对缓存一致性问题有认知这也是评委老师比较爱问的方向。4. 开发中的硬骨头图片体积、导航栏适配与抓包调试4.1 电商图片优化的四个着手点热搜词里电商图片优化查的人很多确实电商页面性能大头就在图片。我的优化分四层来做。第一层是控制源头。商品主图高度统一压缩到750px宽度以内既保证清晰度又控制体积详情页大图改用WebP格式同等视觉效果下体积比JPG小约三成小程序image组件是支持WebP的可以放心用。第二层是懒加载。列表页的image标签加一个lazy-load属性微信会在图片即将进入可视区域时才真正发起网络请求。这个属性在小程序的page页面里有效如果你把商品卡片封装成了自定义组件懒加载就可能失效需要在组件内部自己用IntersectionObserver或监听滚动去实现。第三层是CDN加速。把图片放到对象存储并开启CDN用户在不同地域访问时能就近拉取差不多等于把图片快递到用户家门口。我在云服务商购买了对象存储和CDN流量包花费非常低但对系统加载速度的提升是肉眼可见的。第四层是缓存刷新。小程序对网络图片默认有缓存但商品图片经常变动用户看到的可能是旧图。我的做法是在图片URL后面拼上版本号参数比如main_image?version20240520版本号变了就强制拉新图。4.2 顶部导航栏高度与安全区适配微信小程序顶部导航栏高度这个问题我是在真机测试时被狠狠教育了一顿。同一套代码在iPhone 14 Pro Max上头部间距正常换成红米K60就出现双倍高度按钮整个往下掉。原因很简单不同机型的系统状态栏高度不一样刘海屏、灵动岛、挖孔屏的基础数值都不同如果你在样式里写死了一个padding-top: 44px换机型必错。正确的适配方案分两步。第一步用wx.getSystemInfoSync()获取状态栏高度statusBarHeight。第二步用wx.getMenuButtonBoundingClientRect()获取右上角胶囊按钮的位置信息然后按社区验证过的公式计算导航栏高度const systemInfo wx.getSystemInfoSync(); const statusBarHeight systemInfo.statusBarHeight; const menuButton wx.getMenuButtonBoundingClientRect(); // 胶囊按钮上下留白之和 const navBarHeight menuButton.height (menuButton.top - statusBarHeight) * 2;把自定义导航栏组件的padding-top设为statusBarHeight高度设为navBarHeight全机型基本都能对齐。还有一个小细节页面滚动时如果头部要吸顶别忘了给页面容器的height设置为100vh并开启scroll-view的enhanced模式否则在部分安卓机型上吸顶会失效。4.3 用Charles抓包排查小程序请求排查前端到底发了什么数据、后端到底返回了什么这类问题Charles是效率最高的工具。配置流程是电脑安装Charles → 打开Proxy菜单确保抓包功能开启 → 手机或开发者工具配置HTTP代理指向电脑IP和端口8888 → 安装并信任Charles的SSL证书抓HTTPS必须要这步→ 在微信开发者工具中勾选不校验合法域名或配置代理环境。Charles最有价值的地方不只是看请求而是能改请求做Mock测试。比如我需要验证前端商品列表为空的空态页面时直接把某个商品列表接口的响应改成空数组前端立刻渲染出空态。这个方法比在后端删数据库再重启服务高效太多了。另一招是断点拦截Charles支持在请求发出前或响应返回前打断点我可以模拟网络超时、模拟错误返回码把前端所有异常处理分支都测一遍。答辩时你可以说系统经过了异常输入和异常网络状态的测试这些测试截图就是从Charles截的。4.4 小程序项目的启动与体验版发布很多新手同学不知道怎么把一个微信小程序项目跑起来。流程其实很简单下载微信开发者工具 → 用微信扫码登录 → 点击导入项目 → 选择小程序项目的根目录注意是包含app.json的那一层→ 填自己的AppID没有就选测试号→ 工具自动编译并打开模拟器。如果你拿到的是别人分享的完整项目导入后先看project.config.json里的appid配置改成你自己的AppID否则部分接口会不可用。演示给老师看时建议用体验版而不是让老师在模拟器里看。开发者工具右上角有个上传按钮把代码上传后到微信公众平台版本管理里把该版本设为体验版生成体验版二维码然后在小程序管理后台的成员管理里把老师的微信号加为体验成员老师扫码就能在手机上看到完整效果。这里要提前确认后端接口域名必须在公众平台配置好白名单否则真机体验版所有请求都会失败。5. 毕业论文写作与答辩准备的实操心得5.1 论文结构七章方案与国内外研究现状的写法我的论文采用了经典七章结构绪论、相关技术介绍、系统需求分析、系统概要设计、系统详细设计与实现、系统测试、总结与展望。这个结构是大多数高校软件工程专业的默认预期照着写不会出大错。绪论部分最难写的是国内外研究现状也是最容易被写成流水账的章节。我的做法是层层收窄先写宏观背景引用国内电商行业的数据说明移动电商已经是主流消费形态这是从权威行业报告里能找到的公开数据然后收窄到小程序电商说明小程序即用即走、社交裂变的特点恰好弥补了传统电商App获客成本高的短板最后引出优购电商的具体定位——一个面向大众消费者的轻量级购物小程序基于SSM框架实现重点解决浏览、下单、支付、订单管理的全流程问题。关于关键词的布局我要提醒一下论文题目里的基于微信小程序的优购电商的设计与实现这种表述在摘要、绪论、结论里至少要各出现一次且描述一致。盲审老师和查重系统都盯着题目的关键词看表述不一致容易被判定为内容偏离。5.2 系统实现章节截图、图表与代码的黄金配比系统实现章节占据论文三分之一的篇幅最容易得分也最容易显得空洞。我的写作经验是每功能必配图每流程必配表。每个核心功能的实现描述遵循三段式功能描述 → 关键代码讲解 → 运行效果截图。功能描述交代需求背景关键代码挑核心逻辑片段不要贴大段源码挑Controller里的核心方法或XML里的核心SQL用文字解释每行的作用运行效果截图必须是真机或模拟器的真实页面。流程图和用例图我统一用ProcessOn画实体关系图用Navicat的逆向功能生成数据库关系图再稍作调整。这里有个过来人经验开发过程中随手截图不要等到最后再补。很多页面状态比如购物车为空的提示、订单超时的提示是一次性的事后根本复现不出来我当时因为没有随手截图的习惯最后补测试截图时费了很大劲。5.3 系统测试章节测试用例表与边界场景系统测试章节最忌写成所有功能均测试通过系统稳定运行这是空话。我的做法是设计了一张完整的测试用例表字段包括用例编号、测试项、前置条件、操作步骤、预期结果、实际结果、是否通过。每个模块至少三个用例覆盖正常流程和异常流程。以商品分页加载为例我的测试用例表写了三个用例常规用例是正常向下滑动加载三页数据预期结果是无重复无遗漏边界用例是快速滑动到底部十次预期结果是请求不会重复发送且列表无重复数据异常用例是断网状态下滑动底部预期结果是页面有toast提示且网络恢复后可继续加载。这三个用例配上Charles抓取的请求时序截图整个测试章节的含金量就出来了。5.4 答辩答辩高频问题清单与回答思路答辩准备我梳理了一份高频问题清单基本覆盖了评委可能问的方向第一个问题是SSM里三个框架各自干什么。标准回答是Spring负责对象创建和依赖注入SpringMVC负责接收HTTP请求并分发到对应的Controller方法MyBatis负责把SQL语句和Java对象映射起来。我建议把这句话背下来这是最基础的送分题。第二个问题是为什么用token不用session。因为小程序是前后端分离的架构Http请求默认不携带Cookie而且通过SessionId维持会话状态存在跨域、集群部署时的同步问题。Token无状态、天然适合分布式部署、服务端可以单独控制过期时间。第三个问题是库存超卖如何避免。直接答乐观锁的SQL方案并说明为什么不用悲观锁——悲观锁会导致数据库连接长事务等待并发性能差在电商这种读多写少的场景下不划算。第四个问题是如果用户量大了系统的瓶颈在哪。我的回答是数据库查询压力最大优化思路是商品表加索引、热点数据加Redis缓存、图片走CDN、数据库做读写分离、订单表按月分表。不要求你真实做过这些但你能说清方案选型和原因评委就会觉得你有扩展性思维这是区分只敲了代码和理解了系统的关键。第五个问题是你这项目的亮点是什么。不要说什么功能齐全、界面美观这类空话我当时的回答集中在两个点一是通过乐观锁解决了并发下单的库存超卖二是通过自定义导航栏组件完成了不同机型的全兼容。这两个点都有具体的代码和测试数据支撑一说出来评委就知道这是你实际做过的东西。5.5 写论文和答辩的一点提醒论文写作的过程会比你想象中枯燥也会比想象中暴露问题。我在写系统详细设计与实现时被迫回头翻代码里很多当时没在意的细节比如某个接口的异常分支为什么这样设计、某个状态流转的边界条件是什么。这个过程虽然痛苦但确实能帮你把系统的每一个角落都理清楚。答辩前一晚我做了两件事一是把系统所有核心功能在真机上完整演示了三遍确保付款流程、订单流转、个人中心这些关键链路不出岔子二是把论文里的图表编号和所有术语统一检查了一遍避免答辩时被指出低级错误。结果整个答辩过程很顺畅评委问的问题基本都在我准备的范围里一个半小时就结束了。6. 做过这个项目后的几点实在体会整套流程走下来我最深的感受是毕业设计的价值不在于你用了多前沿的框架而在于你有没有把最基础的事情做到位。技术上SSM加原生小程序确实是老一套但正因为老网上资料极多、踩坑经验丰富几乎你遇到的每一个报错都能搜到解决方案。而且这老一套能完整覆盖一个电商项目的所有核心环节前端页面交互、后端接口、数据库设计、并发控制、缓存优化该有的都有了。对比那些一上来就分布式加微服务的项目我的系统虽然规模小但每个环节都是我亲手做出来的都能讲明白原理。如果你正在做类似的题目我有几条具体建议第一别急着写代码先花三天把数据库表和接口文档定清楚。我因为一开始没设计好购物车合并逻辑后面返工了两次比预期多花了一周时间。第二开发过程中务必随时截图、随手记录问题。最后写论文时你会感谢自己当时的勤快。第三前端和后端要经常联调不要等两边都写完再对接。小程序端我遇到过最多的就是请求参数名和后端RequestParam不一致的问题这种问题尽早暴露成本最低。第四提前配置好微信公众平台的域名白名单和体验成员不要在演示当天才处理这些流程性的事情。做这个项目最大的收获不夸张地说是第一次完整地理解了一个能用的系统是怎么从需求变成代码的。中间我也一度觉得SSM繁琐、觉得小程序限制多但回头看恰恰是这些限制逼着我去理解请求响应模型、生命周期、业务状态流转这些本质的东西。这套东西做完你再去学Spring Boot、学新型框架会发现底层逻辑全是通的。祝每一个正在赶毕设的朋友都能顺顺利利走完这一程你有任何具体卡壳的地方也欢迎在评论区聊聊我们一起想办法。