1. 先想清楚“爱心商城”和普通电商的区别需求建模阶段别偷懒1.1 从“商城”到“爱心”多出来的那些需求拿到“爱心商城系统的设计与实现”这个题目很多人第一反应是这不就是个购物网站吗商品展示、购物车、下单、后台管理网上模板一堆改个logo就完事了。如果你也这么想那这个毕设大概率会做得平庸答辩时老师问一句“你的系统和普通商城有什么区别”你会当场卡壳。爱心商城的关键词不只是“商城”更是“爱心”。它和传统电商的核心差异在于系统里必须有一条“公益链路”用户购买某个商品后系统要能算出一笔爱心积分或公益金额公益组织要能在后台发布义卖商品、公示善款去向管理员要能审核商品、查看公益项目进展。这些需求不会自动出现在一个普通电商模板里你必须自己建模。我在带毕设时通常会让同学先回答三个问题你的爱心商城采用哪种公益模式是商家入驻后捐出部分利润还是平台自营义卖商品还是用户捐赠闲置物品兑换积分谁来发布商品管理员统一发布还是多个商家/公益组织独立发布爱心积分是单纯展示还是可以兑换商品、抵扣现金、参与公益活动这三个问题直接决定数据库表怎么设计、接口怎么划分、页面怎么组织。很多同学跳过这一步直接打开IDEA写代码写到一半发现订单表和爱心记录表的关系完全对不上再回头改表结构浪费的时间比多花三天做需求分析多得多。1.2 角色梳理并不是只有“用户”和“管理员”两种爱心商城最稳妥的角色划分是三端普通用户前台买家、爱心商家或公益组织商品发布方、平台管理员后台运营方。普通用户注册登录、浏览商品、搜索筛选、加入购物车、下单、模拟支付、查看订单、查看爱心积分明细、参与爱心兑换。爱心商家/公益组织发布商品、编辑商品上下架、处理买家的订单发货、查看自己商品的销售统计。平台管理员用户管理、商品审核、分类管理、公告发布、公益项目维护、全站数据报表。这里有个容易被忽视的点商家端和管理端不能混在一个角色里。有些同学图省事让管理员既管平台又发商品最后商品列表页面同时出现“审核”和“编辑”按钮逻辑混乱。早期把角色和权限边界画清楚后面Controller的接口设计会轻松很多。1.3 把核心业务流程画出来再动手需求建模阶段最实际的做法是用一张用户故事地图把买家的完整链路写下来游客访问首页 → 查看公益头条、推荐商品、爱心公示数据注册并登录 → 获得基础会员身份浏览商品详情 → 查看商品介绍、义卖故事、积分比例加入购物车 → 修改数量、删除商品、批量结算提交订单 → 选择收货地址、填写备注模拟支付 → 订单状态变为“已支付”系统自动计算爱心积分 → 生成积分流水查看订单列表 → 确认收货、查看物流、申请售后积分兑换 → 在积分商城兑换公益周边这张图里隐藏着一个很重要的设计决策爱心积分是在哪个环节产生的答案是订单支付成功后自动产生而不是用户下单时。为什么因为下单不支付订单会被取消积分不应该发放。这条规则不梳理清楚代码里的事务边界就会出问题后面章节我会详细展开。2. Spring Boot Vue前后端分离为什么这是最稳妥的毕业设计技术组合2.1 技术选型的底层逻辑让答辩老师一眼看懂现在做毕业设计技术栈基本绕不开Spring Boot。你在相关热词里看到“基于spring boot的校园讲座预约系统”“基于springboot的高校社团活动管理系统”“基于springbootvue的大学生科创项目申报系统”说明Spring Boot已经成了当前毕设的绝对主流。选择Spring Boot的原因很实际约定优于配置省掉大量XML配置文件开发效率高适合工期紧张的毕设节骤。内置Tomcat打包成jar就能跑部署演示环节特别方便。与MyBatis-Plus、Spring Security、Redis等生态集成非常顺畅资料多遇到问题搜一下就有解决方案。分层架构清晰Controller、Service、Mapper、Entity答辩老师看代码结构时能快速理解你的设计思路。前端选Vue 3 Element Plus是标配。Vue的组件化开发让页面代码可维护性好Element Plus提供现成的表格、表单、弹窗、分页组件后台管理界面不用从零写CSS。前后端分离架构下前端通过Axios调用后端RESTful API数据交互逻辑清晰这在论文里也很好画架构图。2.2 ORM选型MyBatis-Plus是毕设最优解数据访问层我强烈建议用MyBatis-Plus而不是原生MyBatis或者JPA。JPA的坑在于你对关联映射不够熟悉时很容易出现懒加载异常、N1查询问题而且答辩时老师问“你的查询性能怎么样”你很难解释清楚。原生MyBatis虽然SQL可控但大量简单的增删改查要手写XML工作量白白增加。MyBatis-Plus的好处是内置通用Mapper方法insert、selectById、updateById、deleteById直接调用代码量省一大截。LambdaQueryWrapper写动态查询比如多条件筛选商品时可以链式拼接条件清晰直观。分页插件PageHelper一行代码搞定分页前台商品列表和后台订单列表都要用。代码生成器可以根据数据库表快速生成Entity、Mapper、Service、Controller的雏形10分钟搭好项目骨架。举个例子商品列表的筛选查询用MyBatis-Plus写起来是这样的LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(categoryId ! null, Product::getCategoryId, categoryId) .eq(Product::getStatus, 1) .orderByDesc(Product::getCreateTime); PageProduct page productMapper.selectPage(new Page(current, size), wrapper);那一串布尔条件的含义是只有传入了关键词才拼接like条件否则跳过。这样前台传什么参数查询就动态适配什么参数不用写一堆if判断。2.3 辅助组件怎么选才不会在答辩时露怯有些同学喜欢堆技术栈Redis、RabbitMQ、Elasticsearch全上美其名曰“技术亮点”。我要泼一盆冷水毕设的核心是自洽不是炫技。我的建议是区分“核心组件”和“锦上添花”组件用途建议JWT用户认证、Token签发与校验核心必做Redis缓存首页轮播图、商品热门榜、Token黑名单核心做缓存即可Lombok减少Entity类getter/setter代码核心必用Swagger/Knife4j自动生成接口文档推荐写论文时直接截图Spring Task订单超时未支付自动取消推荐业务闭环必须本地文件存储商品图片上传与回显够用不必上OSSRabbitMQ异步处理消息不建议答辩容易追问底层机制Elasticsearch全文检索不建议MySQL的like查询足够撑起毕设场景选每个组件都要想清楚“它解决了什么问题”。比如Redis解决的是首页热点数据频繁查数据库的问题这说法就站得住脚。RabbitMQ在单机毕设场景里没有不可替代的收益反而会引入消息丢失、重复消费等麻烦属于自己给自己挖坑。3. 订单链路与爱心积分最容易出亮点也最容易埋雷的核心业务3.1 订单状态机先定好规则再写代码订单模块是整个系统的核心也是一旦出bug就影响全局的模块。我见过的毕设里订单状态用数字1、2、3、4乱写的特别多后台显示和前端页面经常对不上。规划订单状态时我建议用一个枚举类把状态管理起来而不是散落各处的魔法数字public enum OrderStatusEnum { PENDING_PAYMENT(0, 待支付), PAID(1, 已支付), SHIPPED(2, 已发货), COMPLETED(3, 已完成), CANCELLED(4, 已取消); private final Integer code; private final String desc; OrderStatusEnum(Integer code, String desc) { this.code code; this.desc desc; } // getter... }订单状态的流转规则要提前定死待支付 → 已支付 → 已发货 → 已完成这是一个单向流程不允许跳状态不允许倒流。只有两个特殊旁路待支付超时后自动取消已支付后在发货前用户可申请退款。这里有个毕设答辩高频问题下单时锁库存还是支付时扣库存商业系统里两种方案都有但你要能说出自己的选择逻辑。我建议在毕设场景下采用“支付时扣库存”用户下单后先锁单订单状态为“待支付”此时库存不动用户支付成功后在事务里扣减库存并生成订单明细。这样做的好处是未支付订单不会长时间占用库存超时取消时也不需要恢复库存的补偿逻辑整体简单很多。3.2 爱心积分流水必须走独立表不能只靠一个字段很多同学做爱心积分直接在用户表里加一个total_points字段支付成功后把这个字段加个10完事。这种设计答辩一定被追问用户积分明细怎么看积分规则变了以前的数据怎么追溯积分被错误发放怎么撤销正确的做法是设计一张独立的爱心积分流水表姑且命名为love_points_record字段名类型说明idbigint主键user_idbigint用户IDorder_idbigint关联订单IDtypetinyint积分类型1增加2扣减pointsint积分变化值sourcetinyint来源1订单捐赠2活动奖励3积分兑换扣减remarkvarchar备注比如“购买爱心商品赠送积分”create_timedatetime产生时间用户表里可以保留一个total_points字段做汇总展示但它只是一个冗余缓存真正的数据以流水表为准。每次积分变动时在当前事务里同时执行两条操作往流水表插一条记录、更新用户表的总积分字段。由于这两个操作在同一个事务里要么都成功要么都失败不会出现积分加了但流水没记录的情况。订单支付成功后生成积分的核心代码事务逻辑大概是这样Transactional(rollbackFor Exception.class) public void payOrder(Long orderId) { // 1. 更新订单状态为已支付 Order order orderMapper.selectById(orderId); order.setStatus(OrderStatusEnum.PAID.getCode()); orderMapper.updateById(order); // 2. 遍历订单明细扣减商品库存 ListOrderItem items orderItemMapper.selectList( new LambdaQueryWrapperOrderItem().eq(OrderItem::getOrderId, orderId) ); for (OrderItem item : items) { // 乐观锁扣库存 int rows productMapper.deductStock(item.getProductId(), item.getQuantity(), item.getProductId()); if (rows 0) { throw new RuntimeException(商品 item.getProductName() 库存不足); } } // 3. 计算订单贡献的爱心积分生成流水 int totalPoints calcPoints(order.getTotalAmount()); if (totalPoints 0) { insertPointsRecord(order.getUserId(), orderId, totalPoints, 1); userMapper.increasePoints(order.getUserId(), totalPoints); } }注意代码里order.getTotalAmount()和积分规则是分离的。积分规则应该是可配置项比如“每消费10元赠送1爱心点”而不是在代码里写死if total 100。我会在系统设计里加一张sys_config配置表把积分比例、运费满减阈值等参数放进去后台管理员可以直接改配置不用动代码。这一点在论文和答辩里都是加分项。3.3 未支付订单自动取消用Spring Task做定时清理订单超过30分钟未支付要自动取消否则库存和订单列表都会变得混乱。实现方式很多定时任务轮询、消息队列延迟消息、Redis过期事件。毕设场景下Spring自带的Scheduled定时任务是最简单的方案Component public class OrderAutoCancelTask { Autowired private OrderMapper orderMapper; Scheduled(fixedDelay 60000) // 每60秒执行一次 public void cancelExpiredOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(30); ListOrder expiredOrders orderMapper.selectList( new LambdaQueryWrapperOrder() .eq(Order::getStatus, OrderStatusEnum.PENDING_PAYMENT.getCode()) .lt(Order::getCreateTime, deadline) ); for (Order order : expiredOrders) { order.setStatus(OrderStatusEnum.CANCELLED.getCode()); order.setRemark(订单超时未支付系统自动取消); orderMapper.updateById(order); } } }这里有一个容易踩的坑定时任务执行时需要加上EnableScheduling注解开启Spring的调度支持很多同学忘了在启动类上加这个注解导致定时方法不生效订单永远超时不取消。这个定时任务本身还有一个可优化的点每60秒扫一次全表的待支付订单数据量小时没问题但你可以加一个前提条件只查“创建时间小于deadline”的记录利用create_time索引避免扫描全表体现你考虑过性能问题。3.4 公益透明化用首页展示把爱心场景真正落地爱心商城能不能在答辩时眼前一亮我觉得关键看“爱心”到底有没有落到页面上。只做一个商城加一个积分字段这不算爱心商城。比较推荐的做法是在首页加三个模块公益数据看板展示累计爱心积分总数、累计参与人数、本月公益捐赠金额。爱心公示列表每笔订单支付完成后后台自动生成一条公益记录公开显示订单编号脱敏、商品名称、贡献积分。公益项目专区公益组织发布正在进行的项目展示项目进展图文用户可以直接从项目页跳转到相关义卖商品。这些模块的数据来源并不复杂公益数据看板是几张表的聚合查询爱心公示列表就是积分流水表的公开展示公益项目专区是独立的project表和project_image表。复杂度不高但对主题的契合度非常高论文里的系统功能结构图会因此显得丰满很多。4. 数据库设计十四张表怎么划分才不显得廉价4.1 表结构总体规划从用户到订单一次说明白爱心商城系统的数据库设计我说得直接一点别去整那些花里胡哨的分库分表老老实实把表设计清楚能讲明白每张表的职责和关联关系毕设就达标了。我的建议是将数据库表划分为五个域用户域用户表、角色表、用户角色关联表商品域商品分类表、商品表、商品图片表交易域购物车表、订单表、订单明细表、收货地址表公益域爱心积分流水表、公益项目表、爱心兑换记录表系统域轮播图表、公告表、系统配置表、操作日志表一共16张表不多不少。下面把核心表的关键字段聊一聊。用户表users字段名类型说明idbigint主键自增usernamevarchar(50)登录用户名唯一passwordvarchar(255)BCrypt加密后的密码nicknamevarchar(50)昵称avatarvarchar(255)头像URLphonevarchar(20)手机号total_pointsint爱心积分总数冗余字段statustinyint账号状态0禁用1正常create_timedatetime注册时间商品表product字段名类型说明idbigint主键category_idbigint分类IDnamevarchar(100)商品名称subtitlevarchar(200)副标题比如“山区儿童手工作品”main_imagevarchar(255)主图URLdetailtext商品详情富文本或HTMLpricedecimal(10,2)价格stockint库存salesint销量points_rateint每笔订单赠送积分比例seller_idbigint发布商家/公益组织IDstatustinyint0下架1上架2待审核create_timedatetime创建时间订单表order字段名类型说明idbigint主键order_novarchar(32)订单号业务编号user_idbigint下单用户IDaddress_snapshotvarchar(500)收货地址快照total_amountdecimal(10,2)订单总金额points_amountdecimal(10,2)积分抵扣金额statustinyint订单状态见3.1节remarkvarchar(255)用户备注create_timedatetime下单时间pay_timedatetime支付时间订单明细表order_item字段名类型说明idbigint主键order_idbigint订单IDproduct_idbigint商品IDproduct_namevarchar(100)商品名称冗余防止商品改名后历史订单显示不正常product_imagevarchar(255)商品图片冗余pricedecimal(10,2)下单时单价quantityint购买数量subtotaldecimal(10,2)小计注意一个细节order表单独存了address_snapshot快照order_item表冗余了product_name和product_image。为什么要快照和冗余因为用户下单后地址可能被修改商品可能下架或改名订单属于历史事实数据必须保留下单那一刻的状态。这个设计理念在你的论文里值得写一段它是你思考过数据一致性问题的有力证明。4.2 为什么爱心积分流水表要独立存在关于爱心积分流水表我在上一章已经给出了字段设计这里重点讲讲这张表在整个系统里的位置。爱心积分流水表love_points_record可以理解为公益域的“账本”。用户每一次获得积分、兑换积分都在这张表里留下一条不可抵赖的记录。它存在的意义有三个第一可追溯。管理员在后台查看某个用户的积分时能顺着流水表看到每一笔积分的来源是哪笔订单贡献的、是哪次活动奖励的、什么时候被兑换掉的。如果只有用户表一个字段这些全看不到。第二可对账。用户表里的total_points字段只是一个汇总值如果数据异常比如某次事务没成功可以通过流水表的sum(points)重新汇总修正用户表的积分余额。这相当于给系统加了一个冗余校验机制。第三可展示。前面说的首页爱心公示列表直接查询流水表type1的最近10条记录即可不需要额外设计一张“公示表”省表又合理。4.3 索引设计与统计查询的SQL数据库设计不能只谈字段不谈索引。爱心商城的数据量不会很大但该建的索引还是要有答辩时顺手讲出索引设计思路比默背八股文强。建议至少建立以下索引users.username唯一索引product.category_id普通索引product.status普通索引order.user_id普通索引order.order_no唯一索引order.status普通索引order.create_time普通索引用于超时取消和统计love_points_record.user_id普通索引love_points_record.order_id普通索引索引设计有一条原则索引是给查询用的经常出现在WHERE条件或ORDER BY里的字段才需要建索引。比如后台订单列表要按状态筛选、按时间排序所以order.status和order.create_time都要有索引。公益数据看板需要按月统计积分数据SQL大概是这样的SELECT DATE_FORMAT(create_time, %Y-%m) AS month, SUM(CASE WHEN type 1 THEN points ELSE 0 END) AS total_earned, SUM(CASE WHEN type 2 THEN points ELSE 0 END) AS total_spent FROM love_points_record WHERE create_time 2024-01-01 GROUP BY DATE_FORMAT(create_time, %Y-%m) ORDER BY month DESC;这条SQL在论文的系统测试或数据分析一章可以放进去说明你的系统能够支撑公益数据可视化。create_time上的索引能让这种范围查询走索引而不是全表扫描。5. 答辩前必须能讲清楚的三个技术难点5.1 前后端分离下的JWT认证流程爱心商城既然是前后端分离架构就不能使用传统的Session登录因为Session默认绑定在服务端容器上跨域和接口调用都不方便。JWTJSON Web Token是目前最常用的替代方案。JWT的认证流程是用户提交用户名和密码到后端login接口。后端校验通过后生成一个JWT Token返回给前端。前端把Token保存在localStorage或Vuex中在Axios拦截器里给每个请求头加上Authorization: Bearer 。后端写一个拦截器对所有需要权限的接口校验Token的签名和有效期。校验通过后从Token中解析出userId放行请求校验失败则返回401状态码前端跳转登录页。核心拦截器代码示意public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BusinessException(401, 未登录); } // 去掉 Bearer 前缀校验签名 Claims claims JwtUtil.parseToken(token.replace(Bearer , )); request.setAttribute(userId, claims.get(userId)); return true; } }这里有两个细节值得在答辩现场讲清楚第一个Token里存什么。我建议只存userId和角色信息不要存密码、不要存手机号。Token本身虽然经过签名但它是在浏览器端存的存敏感字段是给自己找麻烦。第二个Token过期时间怎么定。设置太短用户频繁重新登录体验差设置太长Token泄露后风险高。毕设场景下设为2小时或1天都可以。如果你想做得更好一点可以在Redis里存一份“token黑名单”用户登出时把Token加入黑名单过期时间与Token保持一致实现真正的服务端可控下线。5.2 图片上传与回显路径的坑爱心商城里的商品图片、公益项目图片、轮播图都要上传。很多同学在本地测试时写死了文件路径比如把图片保存到D:/upload/xxx.jpg然后数据库里存的是完整路径D:/upload/xxx.jpg。项目一换机器或者部署到服务器所有图片全部失效。正确的做法是上传接口接收MultipartFile文件保存到项目的可配置上传目录比如../upload/商品图片/年月/。生成一个相对路径存储到数据库比如/upload/2025/05/abc.jpg。后端写一个静态资源映射配置把本地目录映射为/upload/**的虚拟路径或者配置web-server路径映射。前端展示时用当前后端地址拼接相对路径或者通过nginx等做路由指向。Spring Boot里的虚拟路径映射配置Configuration public class WebMvcConfig implements WebMvcConfigurer { Value(${file.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir /); } }这个配置的意思很简单所有前端请求/upload/xxx的图片后端都去本地uploadDir目录下找资源返回。这样数据库里存的路径是相对路径图床换了也不影响数据正确性迁移部署时只需要改配置文件里的upload-dir。5.3 并发扣库存下的超卖问题与乐观锁爱心商城的并发量不会很大但“库存为负”这种bug一旦出现非常丢人。如果你的商品列表显示有3件库存两个用户同时下单都支付成功结果库存变成了-1答辩现场演示时就会被当场打脸。超卖问题产生的根因是“先查库存再扣库存”之间存在时间差。两个请求同时查库存都是3都认为可以扣结果都扣了库存变1而不是0。最简单的解决方案是使用乐观锁也就是在扣库存的SQL语句中带上库存条件UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}执行这条SQL后如果受影响行数为0说明库存不足或已经被其他请求扣光此时直接抛出异常让事务回滚。这样就不需要“先查询再判断”的逻辑从根上避免了超卖。如果你还想在答辩时多说一层可以补充如果未来商城做大、并发量升高会考虑把库存数据放到Redis里做预减然后用消息队列异步同步到MySQL。这句话点到即止即可不需要真的在毕设里实现但能证明你了解行业里的常见做法。逻辑也要讲清楚在同一个事务里订单支付、扣减库存、生成积分流水是三个步骤任何一个步骤失败都要全部回滚。比如扣库存失败时不应该让订单变为已支付状态。这就是为什么整个方法必须加Transactional注解的根本原因。6. 论文写作的顺序与方法从需求分析到测试报告的实操建议6.1 论文章节骨架怎么搭先搭框架再填肉爱心商城系统这篇论文的章节我建议按经典软件工程流程来排不要自行发明创造。规范的结构既好写答辩老师也认可第一章 绪论选题背景、国内外研究现状、课题意义、论文组织结构。第二章 相关技术介绍Spring Boot、Vue、MySQL、MyBatis-Plus、JWT、Redis等每项写清楚用途不需要长篇大论每个技术两三段即可。第三章 系统分析可行性分析、需求分析、用例分析、业务流程分析。第四章 系统设计总体架构设计、功能模块划分、数据库设计、接口设计。第五章 系统实现前台购物模块、订单模块、爱心积分模块、后台管理模块的页面展示和核心代码说明。第六章 系统测试测试环境、功能测试用例、测试结果、兼容性说明。第七章 总结与展望总结工作、分析不足、提出改进方向。这套骨架的好处是每一章解决一类问题“现状怎么样”“用什么工具”“要做什么”“怎么做”“做出来什么样”“测出来怎么样”。只要不跑偏论文结构这一关基本稳了。6.2 开发途中顺手攒下的素材写论文时不愁我见过太多同学最后花一周时间熬夜写论文结果发现没有截图、没有测试记录、没有bug修复记录只能临时重新启动项目补截图非常痛苦。我的建议是开发过程中养成三个随手习惯第一个习惯每完成一个功能模块立即截图保存。比如购物车结算成功、订单列表分页、后台商品审核通过、爱心积分明细展示这些界面截图要按模块命名存档写第五章“系统实现”时可以直接拖进文档。第二个习惯每遇到一个需要解决的bug记录解决过程。不用写很复杂三四行就行什么问题、报错信息、怎么定位、怎么解决。这些内容放进论文的“系统实现”或“系统测试”章节特别有说服力答辩时老师问你“遇到过什么难点”你直接用这个素材回答。第三个习惯搭建测试用例表。不要等系统做完才开始测而是开发一个模块测一个模块。测试用例表至少要有编号测试模块测试步骤预期结果实际结果是否通过T001用户登录输入正确用户名密码登录成功跳转首页登录成功通过T002用户登录输入错误密码提示密码错误提示密码错误通过T003商品搜索搜索框输入“马克杯”展示相关商品列表展示相关商品列表通过这张表在论文第六章可以直接复用提前录20~30个用例测试章节就填满了。6.3 答辩高频问题与对应的经典答法最后说一嘴答辩准备。爱心商城系统的答辩问题通常集中在几类我把常见的列出来你需要提前准备好自己的答案而且答案要从自己的代码里来不能背别人的范文问爱心积分和普通积分的区别是什么你怎么体现“爱心” 答积分只来源于订单支付后的公益捐赠金额且有公开公示页面支持追溯系统包含公益项目和爱心公示模块。问为什么选择Spring Boot为什么不直接用SSH 答Spring Boot简化了配置和部署生态成熟内置容器适合快速构建前后端分离项目学习成本比SSH低。问你的订单超时未支付是怎么实现的定时任务如果多实例部署会重复执行怎么办 答使用Spring Scheduling定时扫描订单表中状态为待支付且创建时间早于当前时间30分钟的记录将其置为取消状态。如果未来多实例部署可以用分布式锁如Redis锁保证同一时刻只有一个实例执行该任务。问积分是实时到账还是异步到账 答实时到账因为在支付事务内同步更新积分流水和用户总积分这样可以保证数据一致性。如果未来积分规则复杂、计算量大再改异步方案。问你的系统有什么不足 答目前支付是模拟支付没有接入真实第三方支付单机部署没有考虑分布式场景图片存储在本地后续可迁移到云存储。这类问题只要你真正动手写过代码答起来都不难。怕的是只看了别人的项目讲解视频代码一行没写那确实会被问倒。我个人在带毕设时最深的体会是爱心商城这样的系统技术上并没有多少东西是全新的它真正的价值在于你能否把“爱心”这个主题自然地融进业务流程里。花点时间把需求边界、公益链路、积分流水这些细节想透开发过程反而会比套模板更顺畅论文和答辩也会更有底气。如果时间紧张先把基础商城跑通再补爱心模块每一步都留下记录这趟毕业设计就不会变成赶工灾难。