简介云浮市特色农产品微信小程序交易系统的毕业设计论文完整呈现从课题背景、需求分析、技术选型、系统设计到编码实现与测试评估的科研流程。整体基于Java语言后端采用Spring Boot框架配合MySQL数据库完成数据持久化业务上覆盖用户注册登录、农产品浏览检索、购物车管理、订单提交与物流跟踪、后台商品及订单处理等主要电商环节功能划分清晰。文档共计1个docx文件压缩包约1.13MB正文包含中英文摘要、目录大纲、各章节系统设计说明及部分关键代码逻辑系统功能模块图与数据库设计等内容也能辅助梳理开发思路可作为同类毕业设计或课程项目的论文写作范本。目前已有51人学习浏览适合计算机相关专业学生、准备毕设答辩的毕业生以及刚接触Spring Boot与小程序整合开发的初学者参考借鉴。1. 这不是一个普通的小程序商城SpringBoot 与微信小程序双端毕设工程的拆解每年毕设选题季基于 SpringBoot 与微信小程序的云浮市特色农产品交易系统设计与实现这类题目都会被刷屏但真正能把小程序端、SpringBoot 后端、答辩论文三样东西对上的同学不多。我拆过这套资源结论是难点不在接口有多复杂也不在界面有多炫而在订单状态流转、登录态鉴权、扣库存这三处业务逻辑以及怎么把实现过程写成论文。它适合正在做电商或农业信息化方向毕设、需要一套能跑通并支撑答辩的参考工程的同学。下面从功能蓝图讲起再落到前后端实现与踩坑现场。2. 业务蓝图把农产品交易拆成一张能落地的订单状态机2.1 特色农产品交易与普通商城的三个差异点云浮本地做农产品交易天然要面对非标品问题。普通商城卖的是标品 SKU一部手机只有一个型号、一个价格、一个库存数字而农产品不一样郁南无核黄皮要区分产地、采摘批次、果径大小同一款商品可能上午挂一个价、下午换一批货就改价。所以建表时我一般会把商品拆成product商品基本信息和product_batch批次库存两类而不是把库存直接堆在商品表里。加上特色二字通常还要有产地、认证绿色食品/地理标志等字段这些是答辩评委一眼就能看到的设计亮点。选型上还要考虑分类怎么挂。普通商城的 category 一般是两级一级类目加二级类目农产品我建议直接做成多级树形用parent_id自关联因为水果 柑橘类 郁南无核黄皮这种层级在小程序筛选页是三级联动如果 category 表只有一层后面扩展产地筛选会很痛苦。表结构多一个parent_id字段成本很低但为筛选项省下不少关联查询。第二个差异是交易链条。生鲜不能像数码产品那样下单即发货要处理起批量、每日截单时间、冷链或普通快递这种物流选择。毕设资源里最常见的简化方案是预留物流字段 订单状态机后台管理员手动发货并填入物流单号不接真实快递接口但状态链条完整。第三个差异是支付通道。个人开发者的微信小程序没法直接开通微信支付商户号所以这套资源里普遍采用微信支付接口预留 模拟支付回调的做法前端调起支付按钮后端本地生成一个支付成功的 mock 回调把订单从待付款推到待发货。用这个办法答辩时照样演示完整流程不会被卡在资质上。2.2 订单状态机从待付款到已完成的状态流转设计订单是交易系统的核心也是论文里最值得写的一节。我见过不少同学在订单表里放一个 status 字段代码里随便 set 数字结果出现已发货的订单还能取消退款之后又变成已完成这种逻辑漏洞答辩时被评委一追问就翻车。正规做法是先定义状态机再写代码当前状态可流转到触发动作说明待付款待发货 / 已取消用户支付 / 用户取消超时未支付可定时关单待发货已发货 / 已取消管理员发货 / 用户申请取消发货前取消需管理员确认已发货已完成 / 退款中用户确认收货 / 用户申请退款物流签收后可自动完成退款中已退款管理员同意退款退款后订单不可再操作实际写代码时推荐把状态流转校验收口到一个OrderStateMachine类里订单状态更新统一走transit(newStatus, operator)方法不允许绕过它直接 update status 字段。这个方法先查当前状态再查流转表判断合法性最后写 state_log。如果被问到两个管理员同时操作同一订单怎么办可以在 state_log 表加version字段做乐观锁用受影响行数判断并发覆盖。状态机用枚举 一个二维布尔表来实现最直观。比如在代码里维护一个MapOrderStatus, SetOrderStatus或者简单的canTransit(from, to)方法每次更新订单状态前先校验非法流转直接抛业务异常。这样状态流转变成了黑白分明的一组规则而不是散落在各处 if 里的玄学。论文里把这张流转表画出来再配合订单表加一个 state_log 表记录每次变化的操作人、动作、时间就是一处很实在的加分设计。2.3 六类功能模块与核心表结构的映射这套系统按角色拆开是六个模块用户端的登录注册、商品浏览、购物车、订单与售后、个人中心加上管理端的商品、订单、发货管理。往下落数据库核心只要 8 张表user、category、product、product_batch、cart、order、order_item、address。订单状态日志、支付回调记录这两张表属于加分项有精力就加。模块涉及表关键字段/关系登录注册useropenid(唯一索引)、nickname、avatar、phone商品浏览category、product、product_batchproduct 关联分类与产地库存写在 batch 表购物车cart关联 user 与 product存数量、选中标记订单与售后order、order_item、state_log订单主表 商品明细表 状态日志收货地址address用户可维护多个下单时快照到订单里管理后台product、order上下架、库存调整、发货、退款操作这里有个常见误用把 address 表直接 join 订单用户改完地址历史订单也变了。正确做法是下单时把收货信息快照成 order 表的receiver_name、receiver_phone、receiver_address三个字段订单永远展示下单那一刻的地址。另外购物车表要不要单独建取决于前端是否要求未登录也能加购。毕设建议每次都要求登录后再加购这样 cart 表直接关联user_id前端不用额外维护本地购物车与后端同步两个状态逻辑简单很多演示也不会出现登录后购物车空了的意外。如果想让系统超出普通 CRUD 商城的层次可以加两个小而精的功能。一是搜索联想在 SpringBoot 里集成 HanLP 做农产品名称的分词与拼音匹配用户搜黄皮能带出无核黄皮属于论文创新点但实现成本很低。二是产地溯源地图给商品表加产地经纬度小程序端用天地图组件打点展示罗定稻米、新兴凉果的产区很适合农业信息化方向的题目包装。这两个都算可用可不用的加分项不塞进核心流程避免把毕设做成四不像。3. 小程序端落地从微信登录到购物车对账的完整链路3.1 微信登录code2session 调用链与 session_key 的边界先理解微信登录的完整链路这处黑匣子很多同学没拆开过导致登录一直报错。前端wx.login()拿到的 code 是临时凭证有效期只有 5 分钟且只能使用一次。前端拿到 code 后调自己后端接口后端用 appid、secret、code 去微信服务器换 openid 和 session_key。openid 是用户在小程序里的唯一标识session_key 是微信用于解密用户数据的密钥不能下发到前端。很多教程直接把 session_key 返回给前端用这是安全上的错误示范答辩时被问session_key 为什么不能暴露容易答不上来。// utils/request.js——小程序端请求封装 const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: https://your-domain.com/api url, method, data, header: { Authorization: wx.getStorageSync(token) || }, success: (res) { if (res.data.code 0) { resolve(res.data.data); } else if (res.data.code 401) { // token 失效重新走登录 wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); reject(res.data); } else { reject(res.data); } }, fail: reject }); }); };这段封装把 token 统一塞进Authorization头后端返回 401 时清掉本地 token 并跳转登录页。参数上url用相对路径拼到域名后面header里的 token 从本地存储取这样所有接口自动带鉴权头不用每个页面写一遍。注意wx.login本身不需要用户授权弹窗它与wx.getUserProfile是两回事前者只能拿到 code后者才是用户主动触发昵称头像授权。不要在等待getUserProfile回调时再调wx.login登录态会慢半拍而且容易出现 code 被并发请求重复消费的问题。登录页面里的处理// pages/login/login.js——微信登录 wx.login({ success: async (res) { const loginRes await request(/auth/login, POST, { code: res.code }); wx.setStorageSync(token, loginRes.token); wx.setStorageSync(userInfo, loginRes.userInfo); } });这里的res.code就是临时凭证后端返回的自定义 token 才是后续所有请求的凭证。token 过期时 401 拦截会带你重新走登录清掉旧 token 后再次调wx.login拿新 code这是最稳的闭环。3.2 商品列表加载更多与顶部导航栏的两个适配细节商品列表页有两个高频踩点分页加载和自定义导航栏高度。微信小程序页面里做加载更多最稳妥的是用onReachBottom生命周期页面滚动到底部时自动触发下一页。要避免scroll-view里嵌套onReachBottom失效的问题——onReachBottom只对整页滚动生效如果用 scroll-view 自己滚就得在bindscrolltolower里处理二者别混用。// pages/product/list.js——分页加载更多 Page({ data: { products: [], page: 1, size: 10, hasMore: true, loading: false }, async onLoad() { await this.loadProducts(true); }, async onReachBottom() { if (this.data.loading || !this.data.hasMore) return; this.setData({ page: this.data.page 1 }); await this.loadProducts(false); }, async loadProducts(isRefresh) { this.setData({ loading: true }); const list await request(/product/list, GET, { page: this.data.page, size: this.data.size, categoryId: this.data.categoryId }); this.setData({ products: isRefresh ? list.records : this.data.products.concat(list.records), hasMore: this.data.page list.pages, loading: false }); } });page和size是后端分页参数records和pages是 MyBatis Plus 分页对象的标准返回字段。hasMore通过当前页小于总页数判断避免请求永远停在最后一页。这里有个性能细节下拉刷新时用isRefreshtrue直接替换列表加载更多时 concat 追加不要把两种逻辑写同一个分支。商品图片建议用服务器 URL 并用lazy-load开启懒加载首屏加载会快不少。顶部导航栏的适配是另一个让人挠头的地方。小程序右上角胶囊按钮的位置在不同机型上不一样如果你选择了自定义导航栏navigationStyle: custom标题栏高度需要动态计算// utils/navbar.js——计算自定义导航栏高度 const getNavBarHeight () { const system wx.getSystemInfoSync(); const capsule wx.getMenuButtonBoundingClientRect(); const statusBarHeight system.statusBarHeight || 20; const navBarHeight (capsule.top - statusBarHeight) * 2 capsule.height; return { statusBarHeight, navBarHeight }; };逻辑说明胶囊按钮的 top 减去状态栏高度再乘以 2 加上按钮高度就是导航栏的视觉高度。适配后标题在自己写的导航栏里才能垂直居中否则不同手机上要么顶到状态栏、要么沉下去属于典型的看起来小、做起来烦的适配细节。3.3 购物车与订单提交前端不许自报金额购物车页面的核心是维护选中态和数量每个 cart 项有checked与count两个字段全选、单选都改本地的 data提交订单时只把checkedtrue的项传给后端。这一步前端做得再花哨本质也只是收集参数。// 提交订单的请求载荷 { addressId: 12, items: [ { productId: 101, batchId: 3, quantity: 2 }, { productId: 108, batchId: 5, quantity: 1 } ], remark: }注意载荷里没有金额字段。原因是防篡改原则所有价格、运费、优惠金额都以服务端数据库为准前端只传商品 ID、批次 ID 和数量后端逐项从 product_batch 表取单价重新计算。如果前端直接把总金额 POST 过来抓包改一个数字就能低价下单这在答辩演示时一旦被评委发现是致命的。下单成功后要清掉购物车里对应的项前端可以用filter把已提交的 productId 从购物车列表移除再调一次setData。如果后端库存不足接口会返回业务错误码比如 50001前端要弹提示并把对应商品置灰不能直接忽略。结算页的价格展示可以先用购物车本地缓存但提交时一定要以后端返回的totalAmount为准并刷新页面显示前后端金额不一致时前端要静默覆盖不要自己算一个总额传回去。4. SpringBoot 后端接口约定、登录鉴权与下单并发保护4.1 工程结构与接口约定为什么选 MyBatis Plus后端工程建议用 Maven 构建SpringBoot 版本选 2.7.x配套 MyBatis Plus 3.5.x、JDK 1.8。如果你想用 SpringBoot 3.x 的新特性——比如newVirtualThreadPerTaskExecutor虚拟线程——理论上有性能亮点但 MyBatis Plus 的 starter 要换mybatis-plus-spring-boot3-starter某些旧版 mapper 扫描会不兼容毕设不建议在版本上冒险避坑章节细说。包结构按职责分不是按表分controller接收参数与返回统一结果service写业务逻辑与事务mapper只做数据访问config放拦截器与跨域配置。这个结构答辩时好讲分层清楚、职责单一。选 MyBatis Plus 而不是 JPA 的理由也很直白单表 CRUD 完全不用写 SQL分页插件开箱即用答辩被问为什么用它答一句减少样板代码、内置乐观锁与分页、社区资料多就够了。接口路径方法说明鉴权/api/auth/loginPOSTcode 换 token免鉴权/api/product/listGET商品分页列表免鉴权/api/product/detailGET商品详情免鉴权/api/cart/addPOST加入购物车需登录/api/cart/listGET购物车列表需登录/api/order/submitPOST提交订单需登录/api/order/listGET我的订单列表需登录/api/order/statusPUT状态流转动作需登录/api/admin/order/shipPOST后台发货管理员统一返回结构我习惯用code / message / data三个字段code0 表示成功非 0 是业务错误码。这样前端 request 封装只需判断 code 一个字段不用 catch 各种 HTTP 状态码。4.2 登录鉴权拦截器 自定义注解 用户上下文后端拿到前端传来的 code 后调用微信接口换取 openid// service/AuthService.java——code2session 换取 openid public String login(String code) { // 1. 调微信接口 String url String.format( https://api.weixin.qq.com/sns/jscode2session?appid%ssecret%sjs_code%sgrant_typeauthorization_code, appId, appSecret, code); String resp restTemplate.getForObject(url, String.class); JSONObject json JSON.parseObject(resp); if (json.getIntValue(errcode) ! 0) { throw new BizException(微信登录失败 json.getString(errmsg)); } String openid json.getString(openid); // 2. 查库或注册用户 User user userMapper.selectOne(new LambdaQueryWrapperUser() .eq(User::getOpenid, openid)); if (user null) { user createUser(openid); } // 3. 签发自定义 token return JwtUtil.createToken(user.getId(), user.getRole()); }三个关键参数appid是小程序唯一标识secret是密钥js_code就是前端传过来的临时 code。grant_typeauthorization_code是固定值。后端只把 openid 存库session_key不落库也不返回前端。为什么不用 openid 直接当登录凭证因为 openid 是明文且固定一旦被抓包泄露别人就能伪造你的身份自定义 token 可以加过期时间、可以主动失效紧急时还能把所有登录态一键作废。登录态拦截用 HandlerInterceptor 做最干净// config/LoginInterceptor.java——token 校验拦截器 public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod) { HandlerMethod hm (HandlerMethod) handler; LoginRequired login hm.getMethodAnnotation(LoginRequired.class); if (login null || !login.required()) { return true; // 接口没标 LoginRequired直接放行 } String token request.getHeader(Authorization); UserContext user JwtUtil.parseToken(token); if (user null) { response.setStatus(401); return false; } UserContextHolder.set(user); // 把当前用户放进 ThreadLocal } return true; } }逻辑说明先判断方法上有没有LoginRequired注解没有就放行有注解才校验 token并把用户信息塞进 ThreadLocal。Controller 里就能通过UserContextHolder.get()拿到当前用户 ID不用每个方法都透传 token 参数。拦截器注册时记得排除/api/auth/login和静态资源否则登录接口自己也被拦死。4.3 下单事务与库存扣减别让超卖毁掉答辩下单接口是整套系统里唯一必须加事务的地方。同一个用户可以同时提交两单同一件商品也可能被多个用户抢如果库存扣减写成先查库存、再 UPDATE两步两个请求同时查到剩余 1 件就会双双扣减成功——这就是超卖。经典解法是原子扣减 受影响行数判断// mapper/ProductBatchMapper.java——原子扣减库存 Update(UPDATE product_batch SET stock stock - #{quantity}, version version 1 WHERE id #{batchId} AND stock #{quantity} AND status 1) int deductStock(Param(batchId) Long batchId, Param(quantity) Integer quantity);这条 SQL 把检查库存足够和扣减库存合并成一个原子操作stock #{quantity}条件不满足时 UPDATE 影响行数为 0service 层据此判断库存不足并抛异常。加上乐观锁字段version后续做订单快照或对账时能感知数据是否被改过。下单的 Service 方法长这样// service/OrderService.java——下单核心流程 Transactional(rollbackFor Exception.class) public Long submit(OrderSubmitDTO dto) { // 1. 合计校验遍历 items, 算总金额 BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { ProductBatch batch batchMapper.selectById(item.getBatchId()); if (batch null || batch.getStatus() ! 1) { throw new BizException(商品已下架); } int rows batchMapper.deductStock(item.getBatchId(), item.getQuantity()); if (rows 0) { throw new BizException(库存不足 batch.getProductName()); } // 用 BigDecimal 计算避免 double 精度问题 total total.add(batch.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } // 2. 生成订单主记录与明细 Order order buildOrder(dto, total); orderMapper.insert(order); for (OrderItemDTO item : dto.getItems()) { orderItemMapper.insert(buildOrderItem(order.getId(), item)); } // 3. 模拟支付回调演示用 paymentService.mockPayCallback(order.getId()); return order.getId(); }这里有几个细节要说明。金额字段全部用BigDecimalMySQL 里对应DECIMAL(10,2)商品单价乘以数量时先BigDecimal.valueOf(quantity)再multiply不然 int 自动转 BigDecimal 会丢精度这个是血泪经验。Transactional(rollbackFor Exception.class)指定运行时异常以外的业务异常也回滚不加这个注解前面扣了库存后面插订单失败库存就漏扣了。mockPayCallback是本地模拟支付回调实际接微信支付时这里是签名验证加验重处理论文里把这段讲清楚评委就知道你不只是调了个 demo。订单号生成我一般用yyyyMMddHHmmss userId 4 位随机数够用且容易从日志里定位问题没必要上雪花算法。5. 避坑与常见问题毕设现场最容易翻车的六个点5.1 真机预览白屏、接口全挂request 合法域名没配现象开发工具里一切正常手机扫码预览后页面空白控制台报url not in domain list。 原因微信小程序对wx.request的域名有严格白名单限制真机上任何不在白名单的域名直接拦截开发工具默认不校验所以没暴露。 解决开发阶段在详情—本地设置勾选不校验合法域名、web-view、TLS 版本以及 HTTPS 证书让真机可以访问本地局域网 IP上线前在小程序管理后台配置 request 合法域名且域名必须备案、必须 HTTPS。注意开发者工具里的勾选只对当前项目生效换一台电脑联调就得重新勾这个有点玄学但确实是每次都要查的第一步。5.2 登录报 40029 / 40163code 已失效或被重复使用现象登录接口偶发报errCode 40029 invalid code连续快速操作时报40163 code been used。 原因code有效期 5 分钟且只能用一次。常见误用是把 code 缓存下来做静默登录或者前端在多个页面同时调wx.login后一个请求把前一个 code 顶掉了。 解决后端在收到 code 后立刻调微信接口换取 openid不缓存 code前端只在登录页调一次wx.logintoken 过期时重新走完整登录流程不要并发发两个登录请求。如果换了 appid老 code 也全部失效记得检查 config 里的小程序 appid 与开发工具实际加载的是不是同一个。5.3 SpringBoot 版本太高MyBatis Plus 扫描不到 Mapper现象启动后所有 mapper 注入失败报NoSuchBeanDefinitionException但代码反复检查没问题。 原因SpringBoot 3.x 改了自动装配机制老版 MyBatis Plus3.5.2 及以前的MapperScan加载路径不兼容同理 JDK 17 上升级来的有些配置类也会静默失效。 解决毕设不要追版本。我一般固定spring-boot-starter-parent 2.7.18mybatis-plus-boot-starter 3.5.3.2 JDK 1.8这套组合我跑过的项目没出过兼容问题。如果已经在 3.x 上了换mybatis-plus-spring-boot3-starter并按 3.5.3 官方文档重配分页插件。5.4 小程序包体积超 2MB上传失败现象编译通过但上传时提示source size 2612kb exceed max limit 2mb传不上去。 原因小程序上传时的体积上限是 2MB开启分包后单包 2MB、总包放大到 20MB超了基本都是本地图片、本地字体、未压缩的 JSON 占空间。常见误用是把商品图片直接放项目 static 目录里本地跑没问题一发版就卡住。 解决商品图全部传服务器或对象存储小程序里只存 URLtabBar 图标压缩到 2KB 以内能用 iconfont 就用 iconfont用开发者工具的代码质量—依赖分析看哪些文件占了体积把大的数据文件拆到分包subpackages里。用 uniapp 打包的同学还要留意 vendor.js它经常一个人吃掉半包体积需要单独做分包优化。本地想快速验证时图片可以先用外链图床正式演示再切回自己服务器。5.5 抓包工具抓不到小程序的请求现象想用 Charles 看接口返回开了代理后小程序页面直接无网络或者只能看到 CONNECT 请求。 原因小程序请求走 HTTPSCharles 需要先安装并信任根证书另外部分请求不经系统代理走的是 HTTP 代理或直连导致工具里看不到。 解决开发阶段给小程序端临时用 http 地址加开发工具不校验合法域名Charles 的 SSL Proxying 里把目标域名和端口加进白名单然后设置Proxy SSL Proxying Settings。注意抓包只用于本地联调上线前记得把地址改回 https 并撤掉调试开关我见过不止一个同学把 http 调试地址忘在代码里发上去的。5.6 后端能跑、小程序连不上localhost 与局域网 IP 的差别现象后端在电脑上启动正常小程序开发工具也能打开但所有请求超时。 原因小程序运行在微信开发者工具的模拟器里localhost 指向的不是你的电脑而是模拟器自身所以http://localhost:8080必然连不上。 解决把请求地址改成电脑的局域网 IP例如http://192.168.1.8:8080并保证小程序和后端在同一网段手机预览时手机和电脑也要连同一个 WiFi。后端启动参数上server.address不要绑127.0.0.1直接默认绑定所有网卡否则局域网照样访问不到。这一步是新手卡得最多的地方也是最快的后悔药先 ping 通 IP再排查端口和防火墙。6. 把实现变成论文ER 图表单、第三章组织与答辩演示路径6.1 核心表结构清单直接映射 ER 图论文第二章的数据库设计可以直接用下面这套表清单字段不用全抄关键是关系不能画错表关键字段与其他表的关系userid、openid、nickname、phone、role1:N 购物车 / 订单productid、category_id、name、origin、certificationN:1 分类product_batchid、product_id、price、stock、statusN:1 商品库存与价格放这里cartid、user_id、product_id、batch_id、quantity、checked关联 user 与 productorderid、order_no、user_id、status、total_amount、receiver_*N:1 用户状态机主表order_itemid、order_id、product_id、batch_id、quantity、priceN:1 订单addressid、user_id、receiver_name、receiver_phone、detailN:1 用户state_logid、order_id、from_status、to_status、operator、create_time订单状态履历画 ER 图时注意把 product_batch 画成 product 的子实体order_item 是 order 与 product 的关联实体这两处画对了评委的第一印象就是这同学真的建过表。6.2 论文第三章的组织节奏需求分析写用例图时把角色拆成消费者和后台管理员两个 actor用例按浏览商品、管理购物车、下单支付、订单管理、商品上下架、发货退款六个画不要画登录注册这种人人都有的用例充数。紧接着直接给出第 2 章那张订单状态流转表再用一段话说明 state_log 的用途数据库设计章就不空了。6.3 答辩演示路径的设计答辩时按消费者操作闭环→管理员操作闭环→技术点复盘三步演示先用小程序端完成浏览商品、加购、结算、模拟支付、查询订单再切后台管理端对该订单执行发货、用户确认收货最后看一遍数据库里 state_log 表的状态变化记录。技术点复盘时主动讲三个亮点库存原子扣减 SQL、订单状态机枚举校验、token 鉴权拦截器这三处刚好对应前面 4.3、2.2、4.2 的代码答得上细节就立住了。演示前把本地依赖的 MySQL 数据和图片 URL 做好备份不要在答辩现场重新导数据。这套资源里的源码工程和论文文档一起下载下来把表结构和状态机对照着改很快就能跑通。从那以后我每做一个毕设项目都先把订单状态流转图画在白板上再写代码数据字段和流程对不上就先停下梳理这是被超卖和状态错乱两次翻车换来的习惯。希望帮到你。本文还有配套的精品资源点击获取