毕设选题这件事每年都有人纠结到头秃。如果你让我给个稳妥的建议基于Spring Boot的微信小程序商城这个方向基本上是难度适中、工作量饱满、答辩有故事可讲的典型代表。我今年带过的几个学生里就有选文具商城这个题材的——既不是烂大街的“校园二手交易”也不是那种一眼看上去就超出毕设工作量的全品类电商文具这个切入点刚刚好需求逻辑简单清晰商品数据容易造下单流程完整还能把支付、订单状态、后台管理这些关键模块全部串起来。这个项目说白了就是一套“小程序端下单 Spring Boot后端处理业务 MySQL存数据”的前后端分离应用。用户打开微信小程序浏览文具分类把喜欢的商品加进购物车下单后模拟支付订单进入待发货状态管理员在后台维护商品、处理订单。整个链路麻雀虽小五脏俱全非常适合用来做毕业设计也适合刚学完Java Web想找个完整练手项目的同学。这篇文章我不打算写那种教科书式的流水账而是把我实际带项目、帮学生调代码过程中积累的东西拿出来讲技术选型为什么这么定、数据库该注意什么、小程序和后端联调时那些最折磨人的bug长什么样、怎么规避全是实操层面的东西。1. 项目整体设计与技术选型拆解1.1 为什么选文具商城这个切入点先聊选题。毕业设计最怕的不是难是“做出来说不清”。指导老师问你这系统解决什么问题、核心流程是什么你支支吾吾答不上来那就很被动了。文具商城的好处在于它的业务模型足够小而清晰用户、商品、购物车、订单、支付、后台管理这六个词基本把整个系统说完了。没有复杂的社交关系、没有多角色协同的权限迷宫也没有需要行业知识才能理解的业务规则。但为什么我不推荐你做那种只有一个表格增删改查的“商城”因为不够。毕设评审看的是你能不能体现一个完整的业务闭环。文具商城的闭环是这样的小程序端浏览商品、加入购物车、提交订单、支付哪怕是模拟支付、订单状态流转、后台发货、用户确认收货。这个链路把前端交互、后端接口、数据持久化、状态管理全串起来了你在答辩的时候就能按这条线讲清楚“用户是怎么走完一次购买流程的”这比讲十个孤立功能模块要有说服力得多。再说品类。文具商品的字段很好造名称、分类、价格、库存、图片、描述、销量没了。不像服装要拼SKU尺寸颜色组合不像数码产品要搞参数对比更不像生鲜那样要处理配送时效。文具的规格无外乎“0.5mm黑色中性笔”这种程度属性少非常适合做第一套完整的全栈项目。以后想扩展加个“笔记本”分类也就是一张表的事。1.2 技术栈选型Spring Boot 微信小程序配MySQL选型这块很多人纠结要不要用Vue做后台或者要不要上uniapp跨端开发。我的建议是稳住用最小可行组合Spring Boot 2.7 MySQL 5.7或8.0 微信小程序原生框架。这个组合有两个关键优势。第一个优势是跟课程知识衔接最顺。大多数计算机专业的Java课程、实训项目都建立在Spring Boot上你对注解、依赖注入、ORM这些概念已经有肌肉记忆了写后端不用重新学框架。小程序端用原生语法也就是WXML、WXSS、JS没有额外引入跨端框架学习成本低出问题查资料也最直接。别小看这一点毕设是有截止日期的你花两周学一个新框架答辩时还容易被问住不如在自己熟悉的路上精耕。第二个优势是部署成本低。Spring Boot内置Tomcat打包成一个jar就能跑MySQL装好后导入SQL脚本即可小程序只要在微信公众平台注册个小程序账号个人主体就行。本地开发时开发者工具里勾选“不校验合法域名”直接把请求打到本地IP就能联调。整个部署链路没有Nginx反向代理、没有Docker容器编排这些额外负担省下来的精力全部用来打磨核心功能和文档。等你有余力了再加Redis缓存、加Docker部署那是加分项不是必需品。顺便说一句关于uniapp的纠结。我理解很多人想一次写码多端复用但毕设场景里这个红利你根本吃不上——你要么只交一个小程序要么“小程序H5App”三端全上。后者工作量直接翻三倍而且uniapp和原生小程序在某些组件行为上还不太一样联调阶段容易两头不是人。真想做跨端的等工作或接私活时再搞毕设求稳。1.3 功能模块划分用户端与后台各管什么我习惯把功能梳理成两张清单一张是用户能看到的一张是管理员能看到的。用户端小程序核心功能微信登录通过wx.login拿到code后端调微信接口换取openid生成自己系统的token首页轮播图、热销推荐、分类快捷入口商品列表按分类浏览、关键词搜索、分页加载商品详情图片预览、规格选择、数量加减、加入购物车购物车增删改查、选中结算订单提交订单、订单列表、订单详情、取消订单、确认收货个人中心登录态展示、我的订单入口、收货地址管理后台管理端我建议做一个简单的Web管理页面。用Spring Boot Thymeleaf或者单独用Vue都行毕设里最常见的是低成本方案一个Bootstrap风格的后台就够商品管理新增、编辑、上下架、库存修改分类管理维护文具分类订单管理订单列表、发货操作、查看订单详情数据统计简单展示商品销量、订单数、交易金额用图表插件画两个图即可这个划分的核心思路是让小程序的“用户侧闭环”和后台的“管理侧闭环”都能独立演示。答辩演示时你左边用小程序模拟用户下单右边切到后台把订单发货这种“台下老师看着你演示完整交易链路”的效果是整个答辩最高光的时刻。2. 微信小程序端的核心实现2.1 项目骨架与页面结构小程序端的目录规划我建议一开始就按功能分好文件夹不要把所有页面堆在pages根目录下面后期会很痛苦。我的习惯是这样的miniprogram/ ├── pages/ │ ├── index/ # 首页 │ ├── category/ # 分类页 │ ├── goods/ # 商品详情页 │ ├── cart/ # 购物车 │ ├── order/ # 订单列表 │ ├── order-detail/ # 订单详情 │ ├── address/ # 地址管理 │ └── user/ # 个人中心 ├── components/ # 公共组件商品卡片、数量选择器 ├── utils/ │ ├── request.js # 请求封装 │ ├── auth.js # 登录态管理 │ └── config.js # 全局配置BASE_URL └── app.js / app.json / app.wxss这个结构没什么高深的但要趁早定下来。我见过太多学生写到后半程页面文件全堆在一个文件夹里目录列表拉三屏都看不完改一个样式要找半天。页面命名也建议直接用英文单词本身别用拼音缩写比如goodlist这种丑且容易写错。2.2 请求封装与登录态管理整个前端的地基微信小程序里最基础的能力是wx.request但你要是每个页面直接调wx.request代码会很快失控。我建议第一步就封装一个统一的请求模块核心做三件事统一拼接baseURL、自动携带token、统一处理错误码。// utils/request.js const config require(./config) function request(url, method, data) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: config.BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, success(res) { if (res.statusCode 200) { // 后端统一返回 { code: 0, data: ..., msg: ... } if (res.data.code 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg, icon: none }) reject(res.data) } } else if (res.statusCode 401) { // token过期重新登录后让用户重试 wx.removeStorageSync(token) wx.showToast({ title: 登录已过期请重试, icon: none }) reject(res.data) } else { wx.showToast({ title: 服务器异常, icon: none }) reject(res.data) } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) } module.exports { get: (url, data) request(url, GET, data), post: (url, data) request(url, POST, data), put: (url, data) request(url, PUT, data), delete: (url, data) request(url, DELETE, data) }登录态是另一个必须提前想清楚的点。小程序的登录流程是wx.login拿到临时code把code传给后端后端拿着code去微信接口换openid和session_key然后后端生成一个自己的token下发。前端把这个token存进wx.setStorageSync之后每次请求带上。这里有个直接关系到体验的细节token的过期策略。我建议在token快过期时静默续期而不是让用户重新登录。最简单的做法是后端在返回token的同时返回一个expireTime前端判断剩余有效期小于一天就重新调wx.login换token。如果偷懒不做续期用户用着用着突然被弹回登录页这种体验在答辩演示时非常尴尬。理论上讲小程序里也可以不搞token直接用openid当用户标识每次请求传openid。但那样做有一个致命问题openid一旦泄露任何人都能冒充你下单、改地址。所以哪怕只是毕设也建议走token这套。答辩时老师问“客户端怎么识别用户”你能讲出“openid只用于首次登录换取token后续接口一律校验token”这句话本身就值不少分。2.3 购物车本地优先还是服务端优先购物车这个模块看起来简单实际上有个架构取舍到底存在小程序本地storage还是存在后端数据库我推荐的做法是“以本地缓存为主登录后同步到服务端”。原因是购物车属于高频操作全走后端接口每加减一次都要等网络返回体验很差纯存本地又会导致换设备丢数据。折中方案是未登录时用本地storage存购物车用户登录后把本地购物车合并到后端之后以服务端数据为准。实际实现时我建议给购物车加一个updateTime字段。每次操作购物车本地和服务端各自更新数据并在返回时带上最后更新时间同步策略用“取较新的版本”可以避免一些边界bug。我踩过的一个坑是用户在小程序里删了某个商品但因为网络原因删除接口失败前端直接把本地storage移除了下次打开购物车一看这个商品又回来了——数据不一致。所以正确的做法是等后端返回成功再更新本地缓存失败就回滚并给提示。前端不要自作聪明地“先删本地再说”这种乐观更新策略在毕设项目里容易翻车。2.4 首页与商品列表的渲染细节首页能不能出效果对第一印象特别重要。我的首页规划是三块顶部轮播图、分类快捷图标、下面热销商品列表。轮播图数据从后端banner表拉不要写死在代码里这样管理员后台能换图答辩时算一个亮点。分类图标可以直接调分类接口动态渲染数量多了加个横向滑动。商品列表页要注意一个常见操作上拉加载更多。小程序里监听onReachBottom事件维护一个pageNum和hasMore状态每次请求带pageNum和pageSize后端返回时带上总数。这里有个细节判断hasMore不能只看“返回列表长度是否等于pageSize”因为刚好等于分页大小时会漏一页。建议后端返回total前端用pageNum * pageSize total来判断是否加载完。商品详情页的规格选择文具商城一般用不着复杂SKU一个分类值比如“黑色/白色”加一个数量选择器就够了。但数量选择器的边界值得注意做减法时不能小于1做加法时不能大于库存这些判断前端要做后端接口也要再校验一遍。记住一个原则前端校验是体验优化后端校验是安全底线永远不要信前端传过来的数字。3. Spring Boot后端的设计与实现3.1 数据库设计的六个核心表数据库设计是整个后端的地基表结构设计得好后面写接口基本是行云流水设计得烂后期改字段改到想吐。文具商城我建议就六张核心表再加一张配置表。用户表CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE, nickname VARCHAR(50), avatar_url VARCHAR(255), phone VARCHAR(20), create_time DATETIME );分类表和商品表CREATE TABLE category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(30) NOT NULL, sort_order INT ); CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT, name VARCHAR(100) NOT NULL, subtitle VARCHAR(200), main_image VARCHAR(255), detail TEXT, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, sales INT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME );购物车表、订单表、订单明细表CREATE TABLE cart ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, product_id BIGINT NOT NULL, quantity INT NOT NULL, checked TINYINT DEFAULT 1, create_time DATETIME, UNIQUE KEY uk_user_product (user_id, product_id) ); CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, total_price DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0, receiver_name VARCHAR(30), receiver_phone VARCHAR(20), receiver_address VARCHAR(200), pay_time DATETIME, deliver_time DATETIME, finish_time DATETIME, create_time DATETIME ); CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT, product_name VARCHAR(100), product_image VARCHAR(255), price DECIMAL(10,2), quantity INT );注意订单表名我用的是orders不是order。order是SQL关键字直接建order表会出各种诡异问题这是新手最容易踩的坑。维度查一下group、desc、status这些也都是高频关键字建表和字段时留个心眼。我给学生的建议是商品表必须冗余存一份商品快照到订单明细里也就是product_name、product_image、price这些字段。为什么因为商品信息是会变的促销改价、下架删除如果订单明细里只剩一个product_id用户查历史订单时看到的是当前价格这会闹笑话的。存快照是电商系统的常规操作毕设里能用上这个点答辩老师会眼前一亮。字段类型也提一下价格一律用DECIMAL(10,2)别用FLOAT或DOUBLE否则0.1加0.2的精度问题会恶心你。销量sales字段允许冗余不要每次统计SUM(order_item)来算销量性能差而且麻烦。3.2 接口设计统一返回结构加合理分层后端接口我建议统一响应结构。Controller层每个接口直接返回一个Result对象结构固定为code、data、msg。code为0表示成功非0表示业务错误。前端请求封装里已经按这个约定在处理。接口清单大致如下模块方法路径说明登录POST/api/auth/login传code返回token首页GET/api/banner/list轮播图列表分类GET/api/category/list分类列表商品GET/api/product/page分页查询商品商品GET/api/product/detail商品详情购物车GET/POST/PUT/DELETE/api/cart/*购物车增删改查订单POST/api/order/create提交订单订单GET/api/order/list订单列表按状态筛选订单POST/api/order/cancel取消订单订单POST/api/order/pay模拟支付订单POST/api/order/confirm确认收货写Controller时不建议堆很厚的Service。毕设的规模Controller直接调ServiceService里放事务和业务判断Mapper负责和数据库打交道三层就够了。不要过度设计也不要在Controller里写SQL。有个小规律Service里凡是涉及写操作方法上加Transactional查操作无所谓。订单创建这个操作尤其要注意加事务因为要同时扣库存、生成订单明细、清空购物车三步缺一不可如果中间抛异常库存扣了订单没生成整个数据就乱了。用事务就能保证要么全成功要么全回滚。3.3 JWT登录鉴权的实现要点后端鉴权推荐用JWT不用引入Spring Security全家桶毕设场景一个拦截器就够了。JWT的好处是无状态后端不需要存session服务器随便重启都不掉线。核心实现是三个部分。第一是生成token用户用code换到openid后用openid作为payload的主键加上过期时间建议7天用一个secret签名。jjwt或java-jwt库都可以网上示例一大堆。第二是拦截器校验。写一个HandlerInterceptor在preHandle里从Header取Authorization去掉Bearer前缀解析token。解析成功就把userId塞到请求attribute里Controller从request里取解析失败返回401。代码骨架大概是这样的public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String auth request.getHeader(Authorization); if (auth null || !auth.startsWith(Bearer )) { response.setStatus(401); return false; } String token auth.substring(7); Long userId JwtUtil.parseToken(token); if (userId null) { response.setStatus(401); return false; } request.setAttribute(userId, userId); return true; } }第三是注册拦截器。在WebMvcConfigurer里addInterceptors登录、首页、商品列表这些公开接口放行其余接口一律过拦截器。这里有一个很多学生容易漏的点拦截器放行的URL匹配用的是Ant通配符/**和/*的区别要搞清楚。/api/auth/login这种要用/**来放行不然登录接口自己都被拦住了你连token都换不到。3.4 微信支付怎么处理毕设阶段的降级方案真实接入微信支付需要企业主体的小程序、商户号、证书、回调域名配置流程长且审核严。毕设阶段我强烈建议做模拟支付用户点支付按钮后前端调后端接口后端记录pay_time、把订单状态从0改成1返回支付成功。在答辩时明确说“这里使用了模拟支付流程真实环境只需接入微信统一下单API”。我见过不少学生头铁去申请微信支付商户号折腾一个月没下来最后只能改模拟支付时间全浪费了。模拟支付也别忘了做回调处理这层逻辑。所谓回调就是支付结果通知。你可以做一个回调接口的占位模拟支付时也走一遍回调更新订单状态这样代码结构上保留了真实接入的扩展点。老师问起来你能说清楚回调的作用是异步确认支付结果、要做幂等处理比支支吾吾强得多。3.5 图片上传与管理商品图片是商城的门面得有上传功能。后端做一个接口/api/upload/image接收multipart文件存到服务器的某个目录返回可访问的URL。这里有一个常见坑开发环境你存到本地E:/upload这种绝对路径前端拼URL访问没问题一旦部署到Linux服务器路径就失效了。建议用一个全局配置属性来配置存储路径比如app.upload.dir开发时指向本地部署时指到服务器目录。如果担心服务器重启丢失可以把图片存到云存储Aliyun OSS或腾讯云COS都行毕设阶段本地目录加配置项就够用。mime类型校验也别忘了只允许jpg、png、webp这些格式文件大小做限制。我见过上传的文件名带中文或空格导致前端加载404的案例原因是URL编码没处理好。稳妥做法是上传后重命名文件用UUID加后缀不要保留用户原文件名。4. 开发中踩过的坑与排查实录4.1 小程序端的经典坑坑1真机预览请求失败模拟器却好好的。这是微信小程序的经典折磨。模拟器里可以不校验域名真机必须走HTTPS合法域名。破解办法是开发阶段在开发者工具详情里的本地设置勾选“不校验合法域名”但这只能救模拟器。真机调试要在微信公众平台的开发设置里把request合法域名配上而且必须是HTTPS。如果你只是本地联调最简单是后端开一个内网穿透或端口映射工具比如ngrok、cpolar这类免费服务把本机端口映射成HTTPS的临时域名临时配到小程序后台。毕设的联调阶段免费额度完全够用。坑2onLoad里拿不到数据。通常是异步请求还没回来页面已经渲染完毕。解决思路是onLoad里先让页面有个loading状态请求回来再setData。还有一类经典问题是onShow里重复拉数据导致页面闪烁。对购物车这类页面要判断是首次进入还是回退进入别傻乎乎每次都刷新。坑3setData的数据量过大。小程序的setData是走原生桥接的数据量太大会卡顿甚至白屏。开发时商品列表一页20条没问题但如果你把整个商品行的全部字段都setData就会明显掉帧。解决办法是列表页只传需要渲染的字段id、名字、价格、图片、数量不要把整个数据库行直接丢给前端。4.2 后端开发的经典坑坑4Spring Boot版本选择。现在Spring Boot 3.x是主流但3.x要求JDK17同时一些老教程里的配置写法都变了。如果你还是学生建议毕设直接上Spring Boot 2.7.x加JDK8或11资料多、兼容性强、自己熟。等答辩完再学3.x也不迟不要在毕设阶段和生态兼容性硬刚。坑5跨域。小程序端的wx.request不算浏览器环境不受CORS限制所以你后端不加跨域配置也能跑。但如果你后台管理页面是浏览器访问的必须要处理CORS。Spring Boot里加一个CorsFilter或者WebMvcConfigurer配置即可设置允许的origin、方法、请求头。注意origin别写星号因为带了Authorization头时星号会导致浏览器拦截得写具体域名。坑6时间格式化。后端返回的LocalDateTime默认序列化出来是类似2025-01-15T10:30:00的格式前端要显示2025-01-15 10:30还得自己转。建议统一配置Jackson的日期格式或者直接在实体字段上加JsonFormat(patternyyyy-MM-dd HH:mm:ss)。顺手把时区也设置一下spring.jackson.time-zoneGMT8不然数据库里的时间差8小时这个坑我进过不止一次。坑7SQL关键字和表名冲突。order是标准SQL关键字直接建orders表能避开group、desc、status这些也是高频词建表和字段时注意处理。很多学生写SQL没跑通第一反应是逻辑错了结果是字段名撞了关键字排查半天。4.3 联调阶段的日志与排查思路联调最大的敌人是信息不对称前端说接口返回500后端说我没收到请求。我的建议是后端从上到下加日志Controller入口打印请求参数Service打印业务关键步骤Mapper层打开SQL日志。这样任何一次异常都能从日志定位到具体环节。给一个我常用的排查路径看前端调试器的Network面板请求有没有发出去URL对不对BASE_URL有没有拼错响应状态码是多少响应体是什么没发出去看request.js的封装大概率是Promise reject之后没走回调发出去但404路径写错或Controller没注册或拦截器放行配置错误发出去但500看后端控制台异常栈90%是空指针、数组越界、SQL语法错误发出去但业务code非0后端逻辑已经跑了看代码分支和参数值这套路径我几乎每次调试都用学生按这个思路自己排查比我直接甩答案有价值得多。日志别嫌多关键时刻一条日志能省两小时。4.4 常见问题速查表症状可能原因处理建议真机请求失败、模拟器正常域名白名单未配置或没有HTTPS配置合法域名开发期用内网穿透登录后刷新失效token未存storage或后端未认证检查Authorization头是否拼接成功订单创建后库存没变没加事务扣库存SQL未执行Service加Transactional时间显示差了8小时时区设置不对配置GMT8时区上传图片打不开绝对路径问题或文件名特殊字符用配置项存路径用UUID重命名购物车数据莫名消失本地缓存更新策略错误等后端返回成功再更新本地storage5. 部署上线与答辩准备5.1 从jar包到服务器后端打包很简单IDEA里Maven面板执行package生成一个xxx.jar然后java -jar xxx.jar就能跑。如果你没有自己的服务器本地运行演示也没问题有服务器的话可以让小程序真机访问直接加分。部署时注意几个事。第一数据库在服务器上装MySQL导入你的SQL脚本改后端配置文件里的数据库地址。第二配置文件把application.yml里的环境相关配置抽出来数据库密码、上传目录这些敏感信息别写死在代码里。第三启动脚本写个start.sh包含nohup java -jar xxx.jar app.log 21 方便重启。这里强烈建议掌握几个Linux基础操作nohup后台运行、chmod加执行权限、netstat -tlnp查看端口占用、tail -f查看日志。这些都会在部署时用到。很多学生平时在Windows上开发到了部署环节卡在基本命令上很可惜。5.2 小程序发布与审核小程序开发完可以在微信开发者工具里上传版本然后到微信公众平台提交审核。学生个人主体的小程序类目选工具生活服务这类审核一般几天能过。审核前记得检查几件事页面里不要放“测试数据”之类的字眼不要出现与文具无关的内容隐私协议链接必须有。如果小程序后台没有配置用户隐私保护指引涉及用户信息的接口线上会直接挂。新版微信对隐私要求很严格登录、获取头像昵称都要在后台声明收集了哪些信息。这个不填上线后一堆功能不可用我见过不止一次。5.3 答辩前的加分项自查答辩不是只演示系统就行的我总结了几个容易被忽视但很加分的准备点。架构图一张画清楚用户、小程序、后端、数据库交互的图讲流程时配合使用。核心流程说明能讲清楚用户下单到发货的流程以及各个状态下订单数据的变化。测试用例简单写几份核心功能的测试用例登录、下单、支付、发货证明你测过。性能优化点哪怕只是列表接口加了分页、图片走CDN、密码加密存储这种小点讲出来都说明你有思考。异常处理比如后端做了参数校验、库存不足提示这些在答辩老师追问时很有用。另外代码风格和注释也是隐藏分。类名、方法名起得规范接口风格统一不要出现a、b、c这种变量名。哪怕代码量不大整洁度上来了评审老师一眼就能看出是认真写的。最后说点实在的。我带过不少做这个选题的学生最大的体会是这个项目能不能做出彩不取决于用了多新的技术而在于你能否把一条完整的交易链路做扎实。Spring Boot和微信小程序这个组合之所以在毕业设计里长盛不衰就是因为它恰好卡在“复杂度刚好”的位置——既要动脑设计数据库和接口又不会把你拖进无止境的技术细节里。如果你正在做这个题我的建议是第一优先级把“浏览商品-下单-支付-发货-收货”这条链路跑通再去考虑加花活功能调试时优先学会看日志和抓包数据一致性比页面美观重要答辩前把核心流程从头到尾多走几遍。等你把这些问题都趟平了你会发现这个毕设给你的东西不只是那本论文还有对一套完整业务系统从无到有的掌控感。希望这篇分享能帮你少走几步弯路做完了记得回来聊聊你又踩了什么新的坑。