拓冰网站定制 
从需求到论文我的Java校园旧物交易系统完整复盘带过的每届计科学弟里总有人把“校园二手交易”做成一个高仿淘宝商品分类、购物车、物流追踪整整齐齐答辩时被评委一句“你这个和闲鱼有什么区别”问得哑口无言。所以当你要做一个Java校园旧物交易系统答案不是“少抄点电商功能”而是先从校园这个特定场景把需求重新捋一遍。这篇东西我会从需求拆解、技术选型、数据建模、状态机设计、核心实现、论文包装、踩坑记录到答辩应对都过一遍全程基于我实际开发这类系统的经验不是那种只有界面截图的项目笔记。先说清楚这东西的定位一个运行在校园网环境内的闲置物品交易平台用户是本校学生和教职工主要解决毕业生离校物品难处理、在校生买新东西太贵、低年级想淘便宜教材和宿舍神器这几件事。技术栈是Java生态最常见的Spring Boot MyBatis Plus MySQL Vue组合适合毕业设计也适合课程设计关键是这套东西我能把论文需要的“需求、设计、实现、测试”四章全部对齐写论文时不至于对着代码编功能。1. 需求不能照抄闲鱼校园场景里的交易有它自己的脾气很多毕业设计翻车翻在“需求分析用别人的功能设计超纲了”。校园闲置交易和闲鱼这类公共C2C平台表面看都是“发商品、聊一聊、交易”但揉进校园围墙里有几个直接改变功能设计的特点。第一是信任半径。校内交易双方线下见面方便教学楼、食堂、宿舍楼下都可能是交货点所以系统不需要复杂的物流体系反而是“线下自提”“见面交易”“宿舍楼栋坐标”这类信息要给足。用户在发布商品时填一下所在校区、楼栋、方便交易的时间段成交率会明显比只有“发货地址”的常规电商做法高。第二是商品属性非常典型。教材、四六级资料、小风扇、台灯、篮球、电动车、路由器、显示器单价普遍在几块到几百块之间极少有上千的东西。这意味着交易流程必须轻看中一个商品最快的路径是“站内私聊 当面交易”而不是走完整的支付、物流、确认收货流程。很多学弟在这地方把系统做重了非要接支付接口、发货单号浪费时间还容易触发安全问题。第三是账号体系相对可控。用户是本校学生那注册时的学号校验、邮箱一般是学校分配的edu后缀邮箱校验、管理员审核就可以作为身份认证手段。这又区别于闲鱼的手机号注册校园系统完全可以做成“必须学号姓名辅导员信息审核通过才能发布商品”的模式。结论是功能模块应该分成两端用户端注册登录、商品发布/编辑/上下架、商品搜索与分类筛选、商品详情、收藏、站内私信、求购信息发布、订单确认、交易评价、个人中心。管理端用户管理含学籍信息审核、商品审核、举报处理、订单管理、留言和消息管理、轮播图/公告管理、基础数据统计。把这些写清楚论文第二章“需求分析”就不空了。需求调研可以写问卷调查抽样大一大二和大四学生、访谈宿管阿姨和辅导员、再对比参考闲鱼和转转的功能清单得出这些功能点的依据这比拿别人论文的需求综述改一改要靠谱得多。2. 技术选型Spring Boot MyBatis Plus就够了别被“微服务”带偏技术选型是这个项目第一个容易内耗的地方。有的同学张口就是Spring Cloud Alibaba微服务、分布式事务、消息队列做出来网站可能都跑不动。我说句大实话校园旧物交易系统并发量也就是一个校区几千人同时峰值访问单体架构完全能扛住。我选型的原则是主流、稳定、自己能解释清楚、论文有话可讲。最终用的是这套后端Spring Boot 2.7.x内嵌TomcatMaven管理依赖。Spring Boot的自动配置省掉大量XML代码结构清晰论文里能写“采用分层架构Controller、Service、Mapper”。ORMMyBatis Plus。它和MyBatis比省了单表CRUD的大量XML和JPA比国内教材资料多答辩老师也熟悉。再加上分页插件PaginationInnerInterceptor配合MP的LambdaQueryWrapper写条件查询非常顺手论文里能写“利用MyBatis Plus通用Mapper简化数据访问层开发”。前端Vue 2 Element UI 或 Vue 3 Element Plus。不用框架、裸写HTMLJQuery也可以但用Vue能把前后端分离这个点写进论文演示的时候界面也现代很多。走前后端分离时记得用Nginx做跨域和静态资源代理或者后端统一配置CorsFilter别在答辩现场被浏览器跨境拦截搞得手忙脚乱。数据库MySQL 8.0。理由不太需要解释如果想让论文多一个性能优化点可以加Redis做缓存验证码存储、Token黑名单、热门商品缓存、每日UV统计、超时订单定时扫描。这里要特别叮嘱一句如果不是必须不要为了“显得高级”硬上微服务。你至少要解释清楚网关、注册中心、配置中心、各个服务拆分边界、分布式事务怎么做这些解释不清楚在答辩时是扣分项。反过来你用了单体Redis定时任务每一项都是能现场演示、能深入追问的反而更扎实。安全方面登录态我推荐用JWT而不是Session。理由不是“JWT更好”而是前后端分离项目里Session配合跨域比较麻烦JWT无状态扩展性好论文第三章能写清楚Token交互流程和拦截器校验逻辑。权限上做RBAC用户、管理员两个角色后端拦截器按路径前缀区分权限比如/admin/** 需要管理员身份/api/** 需要登录身份或匿名可访问接口单独放行。3. 数据库设计这几张表定下来了论文数据模型一章就稳了数据库设计是系统最核心的地基也是论文里E-R图和数据库表设计章节的直接素材。我设计这套表的时候踩过一些坑下面按模块说明字段设计思路和理由。3.1 用户表 t_user核心字段id、学号/工号、姓名、密码BCrypt加密存储、角色0普通用户、1管理员、性别、所在学院、专业班级、联系电话、邮箱、头像URL、信用分、状态0正常、1封禁、create_time、update_time、deleted逻辑删除。几个设计理由学号字段要加唯一索引因为校验身份时要用头像不存图片二进制只存URL图片文件上传到服务器本地目录或MinIO对象存储都行信用分是后面做评价和举报处理的基础初始给100分被举报核实扣分低于某个阈值禁止发布商品。逻辑删除字段非常关键用户注销、商品删除都走逻辑删除保留记录用于后台追溯和统计数据同时避免外键关联断裂的问题。3.2 商品表 t_goods核心字段id、用户id、标题、描述、原价、售价、成色9成新/8成新/有使用痕迹等、分类id、校区、楼栋、交易方式线下/邮寄/均可、图片主图URL、状态0待审核、1在售、2已下架、3已售出、4审核未通过、浏览数、收藏数、发布时间、下架时间。售价字段必须用DECIMAL(10,2)不能用Double/Float原因后面踩坑部分细说。状态这个字段看似只有五六个值实际上状态流转是整个系统最复杂的部分用户发布是0管理审核通过是1用户手动下架是2订单成交后是3审核驳回是4后续交易的并发问题都是围绕这个状态来的。3.3 交易订单表 t_order核心字段id、订单号唯一雪花算法生成、商品id、买家id、卖家id、成交价、订单状态0待确认、1已完成、2已取消、3退款/介入处理中、交易方式、预约时间、见面地点、买家留言、创建时间、完成时间。订单这块很多同学会犯一个错误直接套电商的“待付款、待发货、待收货、待评价”全链路。但校园闲置交易只在站内完成“意向确认”真正付款和交付都是线下完成的所以订单状态不需要“已付款”“已发货”这些节点而是“待确认买家发起、卖家同意——已完成双方在线下见面交易后由任意一方确认完成——已取消任意一方在确认前取消”。这样设计不仅贴合实际场景而且论文里能明确说“支付和物流不在本系统范围内这与系统定位有关”。3.4 辅助表收藏表 t_favoriteid、用户id、商品id、create_time做唯一联合索引(user_id, goods_id)防重复收藏。私信表 t_messageid、发送方id、接收方id、关联商品id可空、内容、发送时间、是否已读。这里可以做WebSocket在线聊天推送给系统加分不想做WebSocket就做轮询页面每3秒拉一次未读数也够用。举报表 t_reportid、举报人id、被举报对象类型商品/用户/评论、对象id、举报原因、举报描述、处理状态0待处理、1已处理、处理结果、处理时间。求购信息表 t_wantedid、用户id、标题、描述、期望价格、期望成色、分类id、状态0有效、1已达成、2已下架、发布时间。公告表 t_noticeid、标题、内容、类型、创建时间、是否置顶。轮播图表 t_bannerid、图片URL、跳转链接、排序、状态、创建时间。这套表直接画E-R图关系非常清楚用户1-N商品商品1-1订单这里在设计上让一个商品同时只能有一个有效订单防止一物多卖用户N-M收藏商品通过收藏表用户N-M私信关系。数据库设计章节的“表结构说明”就把这些字段的意义、索引、外键逻辑一一列出可以写很多页。数据库建表DDL片段节选CREATE TABLE t_goods ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 发布者id, title varchar(100) NOT NULL COMMENT 商品标题, description text COMMENT 商品描述, original_price decimal(10,2) DEFAULT NULL COMMENT 原价, price decimal(10,2) NOT NULL COMMENT 售价, condition_level tinyint(4) DEFAULT NULL COMMENT 成色 1-10, 10为全新, category_id bigint(20) DEFAULT NULL COMMENT 分类id, campus varchar(50) DEFAULT NULL COMMENT 校区, building varchar(50) DEFAULT NULL COMMENT 楼栋, deal_type tinyint(4) DEFAULT 0 COMMENT 交易方式 0线下 1邮寄 2均可, main_image varchar(255) DEFAULT NULL COMMENT 主图URL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待审核 1在售 2已下架 3已售出 4审核未通过, view_count int(11) DEFAULT 0, favorite_count int(11) DEFAULT 0, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted tinyint(1) DEFAULT 0, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_category_id (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;建表的两个细节字段类型上数字状态一律用tinyint不要用varchar存“上架”“下架”这种中文评论等可能含表情符号的字段表字符集统一用utf8mb4不要用utf8utf8mb3存不了emoji私信功能就会收到乱码。4. 商品和订单的状态机这块设计好了答辩时能讲十分钟状态机是我觉得这个系统里最容易被忽视但最值得展开设计的一环。它的价值在于所有状态流转都不是随意的一对一的合法路径被定死代码层面可以通过常量校验甚至状态模式来实现。论文里能单独开一节“系统状态流转设计”配合状态图说明是打分亮点。商品状态流转是这样设计的发布后进入“待审核(0)”——管理员审核通过进入“在售(1)”——管理员驳回回到“待审核(0)”或进入“审核未通过(4)”——“待审核”状态下用户可撤回变为“已下架(2)”——“在售”状态下用户主动下架变为“已下架(2)”——“在售”状态下商品被买家发起订单、且订单被卖家确认后商品直接变为“已售出(3)”——“已售出”状态不可再被上架。特别注意一个场景商品被买家A发起订单但卖家还没确认时商品应该仍然显示为“在售”还是“锁定”我的做法是引入一个“锁定标记”字段lock_flag订单发起时把商品lock_flag置为1但status保持“在售”其他人可以看到但不能发起订单避免多个买家同时对同一商品下单。这个字段在订单取消/超时后重置。这个设计的细节很值得在论文里写提问“一个商品同时被两个人下单怎么办”时能答上来。订单状态机的核心节点买家发起订单状态0待确认——卖家同意状态1待交易——任意一方在线下交易完成后确认状态1转为状态2已完成若卖家拒绝或买家取消则进入状态3已取消。另外给“已确认但线下未交付”加一个超时保护订单创建后24小时内未确认通过定时任务自动取消并把商品lock_flag恢复。代码层面可以写一个状态转换校验器private static final MapInteger, SetInteger ORDER_STATUS_TRANSITIONS new HashMap(); static { ORDER_STATUS_TRANSITIONS.put(0, new HashSet(Arrays.asList(1, 3))); ORDER_STATUS_TRANSITIONS.put(1, new HashSet(Arrays.asList(2, 3))); ORDER_STATUS_TRANSITIONS.put(2, Collections.emptySet()); ORDER_STATUS_TRANSITIONS.put(3, Collections.emptySet()); } public boolean canTransit(int from, int to) { return ORDER_STATUS_TRANSITIONS.getOrDefault(from, Collections.emptySet()).contains(to); }这样做的好处是后续新增状态比如“退款处理中”时只改这一个映射的地方就行了。接口层所有可能改变状态的接口先校验canTransit再执行update能防住绝大多数非法请求。5. 核心实现细节下单防超卖、Redis缓存、定时清超时订单5.1 下单接口的防超卖处理前面说了“一个商品同时只允许一个有效订单”怎么落地两个手段要配合数据库层面的锁和唯一性控制以及应用层的状态校验。最简单可靠的是用MySQL的SELECT ... FOR UPDATE把商品行锁住检查状态和lock_flag再做更新Transactional public boolean createOrder(Long goodsId, Long buyerId) { Goods goods goodsMapper.selectByIdForUpdate(goodsId); // 自定义SQL: select * from t_goods where id ? for update if (goods null || goods.getStatus() ! 1) { throw new BizException(商品不存在或不在售); } if (goods.getLockFlag() 1) { throw new BizException(商品已被其他买家锁定); } // 创建订单、锁定商品 goods.setLockFlag(1); goodsMapper.updateById(goods); orderMapper.insert(buildOrder(goods, buyerId)); return true; }有的同学担心FOR UPDATE性能这个场景并发量其实很低锁行的时间也就是几毫秒完全没问题。如果你想让论文里多一点亮点也可以讲乐观锁给t_goods加version字段在“锁定”操作时通过WHERE id? AND version?条件更新更新行数为0说明版本不对则重试或放弃。两种方案各有适用条件我当时是结合写的行锁保证事务内强一致version字段作为乐观锁兜底并展示在论文方案对比中。5.2 Redis缓存怎么用才不显得凑数很多毕设硬凑Redis就是给登录验证码存个值这说服力不太够。我在这系统里实际用到的Redis场景有四个验证码存储图形验证码/邮箱验证码key“captcha:{sessionId}”过期时间5分钟用Redis是因为它自带TTL不用自己写清理逻辑。热门商品缓存商品首页列表、热门推荐列表key“hot:goods:list”缓存10分钟用户在10分钟内多次访问首页走的是缓存而不是DB。这类缓存最怕缓存穿透查不到商品ID时要把空值也缓存一下或者做布隆过滤器论文里能写这个会加分。商品详情计数浏览数、收藏数先写Redis定时异步同步到MySQL避免每次页面刷新都更新数据库。登录Token黑名单JWT本身无状态但管理员封禁某个用户时要让TA立即失效把该用户的JWT uniqueId放进Redis黑名单拦截器每请求检查一次。5.3 超时订单的定时任务用Spring自带的Scheduled就够了Component public class OrderTimeoutTask { Autowired private OrderMapper orderMapper; Autowired private GoodsMapper goodsMapper; Scheduled(fixedDelay 60_000) public void autoCancelTimeoutOrders() { // 找出超过24小时仍在待确认状态且商品仍处于锁定状态的订单 ListOrder timeoutOrders orderMapper.selectTimeoutOrders(nowMinus24Hours()); for (Order order : timeoutOrders) { // 事务内执行改订单状态为已取消恢复商品lock_flag orderService.cancelOrder(order.getId(), 系统超时自动取消); } } }注意fixedDelay表示上一次执行完后隔1分钟再执行而不是fixedRate1分钟1次硬性调度避免任务本身执行时间过长导致的重复调度。多实例部署时记得用SchedulerLock加分布式锁不然两台机器同时跑就会重复取消订单。毕设场景一般单实例就行但这个知识点在答辩的时候提到会显得你考虑过生产环境问题。5.4 JWT登录拦截和RBAC权限后端定义一个拦截器处理Authorization头解析出userId和role放入ThreadLocal的UserContext里。凡是/api/user/**、/api/goods/**这些需要登录的路径拦截器里校验凡是/admin/**路径除了校验登录还要校验role管理员。特别注意跨域请求会先发送一个OPTIONS预检请求拦截器要放行OPTIONS并设置跨域响应头否则前端联调时好端端的接口突然报401很多同学查半天查不出来。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new NotLoginException(); } Claims claims JwtUtil.parse(token); Long userId claims.get(userId, Long.class); UserContext.set(userId, (Integer) claims.get(role)); return true; } }6. 论文那么厚工作量从哪来按章节倒推功能点和写作素材写论文时最愁的是“系统太简单字数凑不够”。我的建议是不要最后才来凑字一开始就按论文章节倒推功能设计让每个技术点都有对应的写作素材。论文第五章一般是“系统实现”你手头要有的素材包括每个核心功能模块的界面截图、核心代码片段不要贴大段完整代码贴关键逻辑、操作流程描述、涉及的接口设计可以用表格列出接口路径、请求方式、参数、返回说明。这些素材在开发过程中顺手整理不要等写论文时重新截。下面是通用论文结构对应的功能映射第一章绪论写校园二手交易的背景引用一些高校二手资源浪费、毕业生甩卖难的数据国内外研究现状可以写闲鱼、转转的二手模式再写国外Freecycle、Gumtree这类平台。注意不要编造文献实在找不到就写“综合各大主流平台的业务模式归纳”。第二章需求分析可行性分析技术、经济、操作三层、用户角色分析学生、教职工、管理员、功能性需求用用例图或用例表、非功能性需求性能、安全、易用性、可维护性。需求这章要跟第一章的功能清单完全对应不能需求里写了购物车实现里没有。第三章系统设计系统总体架构画一个简单的层次图展示层、业务层、数据层、功能模块图、数据库E-R图和表结构、关键业务状态机设计、接口设计。我前面讲的商品状态机、订单状态机、防超卖方案都放这一章。第四章系统实现按“登录注册、商品管理、交易订单、后台管理、站内信”几个模块写每个模块写清楚业务逻辑和关键代码。第五章系统测试功能测试用表格列测试用例用例编号、测试步骤、预期结果、实际结果性能测试可以写用JMeter或Postman压测商品列表接口在Redis缓存开启前后的QPS和响应时间对比。这个对比数据是你自己真跑的答辩老师问细节你也能答。如果想提升工作量推荐三个官方认定的“有用功能”一是用户信用分评价体系交易完成后互评差评扣分信用分影响商品发布数量上限二是个人闲置数据统计发布总数、成交总数、交易成功率、累计省下金额用ECharts画图表三是商品导出报表管理员端按分类/时间导出Excel用EasyExcel。这三个功能都贴近校园场景且实现成本不高论文里还能各写一节。7. 实测踩坑笔记Java开发者最容易栽的六个地方7.1 BigDecimal到底怎么传售价用BigDecimal但JSON序列化后前端拿到的可能是科学计数法“1.2E2”或者前端用Number类型丢失精度。我的做法是统一在BigDecimal字段上加JsonSerialize(using ToStringSerializer.class)让它输出字符串“120.00”前端展示直接用下单再转回BigDecimal。7.2 MyBatis Plus逻辑删除 唯一索引的冲突用户表给学号加了唯一索引又开了TableLogic逻辑删除。问题是用户A注销后deleted1再次注册同一学号时唯一索引判定重复插入失败。这个坑网上讨论很多我用的解决办法是唯一索引建成联合唯一(unique_no, deleted)删掉deleted1的记录才能再插入。建表时注意联合唯一索引让同一个学号最多一条有效记录deleted0历史删除记录可以无限保留。7.3 分页插件总是查不到第二页MyBatis Plus的老朋友了。分页插件不生效最常见原因是PaginationInnerInterceptor没配好或者新版要用MybatisPlusInterceptor而配置里还写的是旧版PaginationInterceptor。还有如果你在自定义SQL里写了“LIMIT”MP的分页插件不会自动拼接“LIMIT ? OFFSET ?”而是原始SQL直接爆掉。解决自定义分页SQL里不要自带LIMIT或者用MP内置的Page参数。7.4 跨域联调被OPTIONS拦死Spring Boot 后端配置CorsFilter但自定义 JWT 拦截器的顺序在 CorsFilter 之前时预检请求根本到不了CorsFilter就返回401。解决有两种拦截器里遇到OPTIONS直接放行上文代码就是这么处理或者更稳一点用WebMvcConfigurer去addCorsMappings并且让拦截器注册顺序晚于CORS配置。推荐第二种。而且注意别把Authorization头漏了allowedHeaders里要包含它。7.5 上传文件的MIME类型校验商品图片上传只检查Content-Type是“image/png”完全不够因为伪造Content-Type太容易了。还要校验文件头魔数PNG文件头89 50 4E 47JPEG文件头FF D8 FF可以在上传时读取文件前几个字节校验。另外上传目录不要放在项目resources里要把真实磁盘路径写在配置文件里重启不丢文件。如果你不想折腾对象存储本地磁盘一个静态资源映射配置足够演示。7.6 定时任务在开发环境跑了“奇奇怪怪”的效果开发时把Scheduled任务加上后经常会遇到每天凌晨零点执行统计本地测试时每次启动都来一遍数据不准还不好调试。我建议所有定时任务加一个手动触发接口/admin/task/run/{taskName}自动跑归自动跑手动触发用于联调论文测试章节也好写“管理员可手动触发统计任务”。7.7 时间字段的时区坑LocalDateTime直接序列化到前端经常差8个小时。统一在配置文件里设置spring.jackson.time-zoneGMT8以及数据库连接串加serverTimezoneAsia/Shanghai前后端时间格式就能对齐。这个坑很隐蔽一开始测接口“创建时间总是比现在慢8个小时”后来检查代码才想起来是连接串没带时区。8. 答辩前夜评委一定会问的七个问题答法我给你备好答辩是最多人心虚的环节。评委不一定把你所有代码看完但一定会问几个固定的“架构和设计”类问题。我把自己被问过、以及帮学弟模拟过的几个高频问题整理出来每个都给一个清晰的回答思路。问题一你这个系统跟闲鱼的区别是什么切入点是“校园场景”。要说清楚信任机制学号审核、交易方式线下为主、无物流、商品范围校园闲置、管理端校内管理员审核这四点最后补一句“闲鱼是综合C2C生态本系统面向封闭校园社区只做低频高信任交易”。这个问答几乎必问。问题二为什么用JWT不用Session答前后端分离部署后端可能需要横向扩展JWT无状态可以任意路由Session有状态扩展时要处理Session共享。但也要承认JWT有服务端无法主动吊销的缺陷所以系统里用Redis黑名单配合封禁功能。能说短板且能给出方案比只吹好话强。问题三商品并发下单怎么解决的把5.1的内容答出来顺手画一下“FOR UPDATE行锁 lock_flag”的执行流程再说乐观锁兜底。这个问题问到说明评委在考察你对数据库并发控制的理解。问题四为什么要用Redis缓存答验证码需要过期时间、热门商品列表降低DB压力、浏览计数减轻频繁写操作。再补一句缓存一致性方案先更新DB再删缓存设置过期兜底就很完整。问题五图片存储为什么不放数据库答二进制数据会增大数据库体积、拖慢备份和查询所以存本地磁盘/对象存储数据库只存URL。如果被追问“URL失效怎么办”就说后台做了文件校验部署时通过MD5比对检查文件完整性。问题六如果用户一直不确认交易怎么办答系统有超时保护订单超过24小时未确认定时任务自动取消并恢复商品锁定状态如果已经线下交易但忘记确认用户可在我的订单里主动确认或申请客服介入管理端可以人工修改状态。顺带把scheduler的代码逻辑演示一遍就行。问题七你的系统有哪些安全性设计把密码加密BCrypt、登录校验JWT拦截器、权限控制角色级别、SQL注入防护MyBatis预编译、XSS过滤后端统一做富文本清洗、文件上传魔数校验、防重复提交都列一遍。这里每一条你都能在代码里定位到具体位置那这题就是送分题。9. 演示现场最容易翻车的三个操作提前规避掉答辩现场演示不是给你展示代码的是展示“系统能跑、逻辑闭合、数据真实”。我见太多学弟因为演示翻了车这里讲三个必查项。第一演示数据不要用空库刚初始化的数据。提前往系统里录好10个以上商品分布在三四个人为账号下分类尽量全一些教材、电子产品、生活用品、运动器材订单里最好有一两单处于“已完成”一单正在“待确认”。这样演示时页面是丰富的评论聊天的界面也有内容可截。第二不要登录态过期。答辩前检查JWT的过期时间不要太短。现场录了新用户、传了图结果提交商品时Token过期页面直接跳登录节奏恨不得全乱。我建议答辩前统一用测试环境账号登录好且把Token过期时间设成8小时。第三数据库连接千万别断。很多同学在演示环境跟宿舍WiFi绑定教室WiFi一变IPMySQL连接池直接爆错误。答辩前把所有服务都跑在笔记本本地数据库也放本地连不上外网也没关系这样最稳。轮播图、商品图片都本地化不要依赖外网图床。如果你能把上面这些流程都过一遍系统本身的完成度、论文的深度、答辩的临场发挥就都闭环了。最后讲点我个人的感受这套系统最花时间的不是CRUD是需求和状态机。把“校园交易”这件事想明白了表设计、代码结构、论文章节是一环扣一环顺下来的。如果你正在为选题发愁或者做了一半发现功能四处漏风回过头来把需求和状态流转再捋一遍八成能救回来。至于系统上线后的运营那些二手交易促成率、用户留存的问题就是另一个“毕业后”的故事了。 Java校园旧物交易系统完整复盘：从需求到论文答辩
从需求到论文我的Java校园旧物交易系统完整复盘带过的每届计科学弟里总有人把“校园二手交易”做成一个高仿淘宝商品分类、购物车、物流追踪整整齐齐答辩时被评委一句“你这个和闲鱼有什么区别”问得哑口无言。所以当你要做一个Java校园旧物交易系统答案不是“少抄点电商功能”而是先从校园这个特定场景把需求重新捋一遍。这篇东西我会从需求拆解、技术选型、数据建模、状态机设计、核心实现、论文包装、踩坑记录到答辩应对都过一遍全程基于我实际开发这类系统的经验不是那种只有界面截图的项目笔记。先说清楚这东西的定位一个运行在校园网环境内的闲置物品交易平台用户是本校学生和教职工主要解决毕业生离校物品难处理、在校生买新东西太贵、低年级想淘便宜教材和宿舍神器这几件事。技术栈是Java生态最常见的Spring Boot MyBatis Plus MySQL Vue组合适合毕业设计也适合课程设计关键是这套东西我能把论文需要的“需求、设计、实现、测试”四章全部对齐写论文时不至于对着代码编功能。1. 需求不能照抄闲鱼校园场景里的交易有它自己的脾气很多毕业设计翻车翻在“需求分析用别人的功能设计超纲了”。校园闲置交易和闲鱼这类公共C2C平台表面看都是“发商品、聊一聊、交易”但揉进校园围墙里有几个直接改变功能设计的特点。第一是信任半径。校内交易双方线下见面方便教学楼、食堂、宿舍楼下都可能是交货点所以系统不需要复杂的物流体系反而是“线下自提”“见面交易”“宿舍楼栋坐标”这类信息要给足。用户在发布商品时填一下所在校区、楼栋、方便交易的时间段成交率会明显比只有“发货地址”的常规电商做法高。第二是商品属性非常典型。教材、四六级资料、小风扇、台灯、篮球、电动车、路由器、显示器单价普遍在几块到几百块之间极少有上千的东西。这意味着交易流程必须轻看中一个商品最快的路径是“站内私聊 当面交易”而不是走完整的支付、物流、确认收货流程。很多学弟在这地方把系统做重了非要接支付接口、发货单号浪费时间还容易触发安全问题。第三是账号体系相对可控。用户是本校学生那注册时的学号校验、邮箱一般是学校分配的edu后缀邮箱校验、管理员审核就可以作为身份认证手段。这又区别于闲鱼的手机号注册校园系统完全可以做成“必须学号姓名辅导员信息审核通过才能发布商品”的模式。结论是功能模块应该分成两端用户端注册登录、商品发布/编辑/上下架、商品搜索与分类筛选、商品详情、收藏、站内私信、求购信息发布、订单确认、交易评价、个人中心。管理端用户管理含学籍信息审核、商品审核、举报处理、订单管理、留言和消息管理、轮播图/公告管理、基础数据统计。把这些写清楚论文第二章“需求分析”就不空了。需求调研可以写问卷调查抽样大一大二和大四学生、访谈宿管阿姨和辅导员、再对比参考闲鱼和转转的功能清单得出这些功能点的依据这比拿别人论文的需求综述改一改要靠谱得多。2. 技术选型Spring Boot MyBatis Plus就够了别被“微服务”带偏技术选型是这个项目第一个容易内耗的地方。有的同学张口就是Spring Cloud Alibaba微服务、分布式事务、消息队列做出来网站可能都跑不动。我说句大实话校园旧物交易系统并发量也就是一个校区几千人同时峰值访问单体架构完全能扛住。我选型的原则是主流、稳定、自己能解释清楚、论文有话可讲。最终用的是这套后端Spring Boot 2.7.x内嵌TomcatMaven管理依赖。Spring Boot的自动配置省掉大量XML代码结构清晰论文里能写“采用分层架构Controller、Service、Mapper”。ORMMyBatis Plus。它和MyBatis比省了单表CRUD的大量XML和JPA比国内教材资料多答辩老师也熟悉。再加上分页插件PaginationInnerInterceptor配合MP的LambdaQueryWrapper写条件查询非常顺手论文里能写“利用MyBatis Plus通用Mapper简化数据访问层开发”。前端Vue 2 Element UI 或 Vue 3 Element Plus。不用框架、裸写HTMLJQuery也可以但用Vue能把前后端分离这个点写进论文演示的时候界面也现代很多。走前后端分离时记得用Nginx做跨域和静态资源代理或者后端统一配置CorsFilter别在答辩现场被浏览器跨境拦截搞得手忙脚乱。数据库MySQL 8.0。理由不太需要解释如果想让论文多一个性能优化点可以加Redis做缓存验证码存储、Token黑名单、热门商品缓存、每日UV统计、超时订单定时扫描。这里要特别叮嘱一句如果不是必须不要为了“显得高级”硬上微服务。你至少要解释清楚网关、注册中心、配置中心、各个服务拆分边界、分布式事务怎么做这些解释不清楚在答辩时是扣分项。反过来你用了单体Redis定时任务每一项都是能现场演示、能深入追问的反而更扎实。安全方面登录态我推荐用JWT而不是Session。理由不是“JWT更好”而是前后端分离项目里Session配合跨域比较麻烦JWT无状态扩展性好论文第三章能写清楚Token交互流程和拦截器校验逻辑。权限上做RBAC用户、管理员两个角色后端拦截器按路径前缀区分权限比如/admin/** 需要管理员身份/api/** 需要登录身份或匿名可访问接口单独放行。3. 数据库设计这几张表定下来了论文数据模型一章就稳了数据库设计是系统最核心的地基也是论文里E-R图和数据库表设计章节的直接素材。我设计这套表的时候踩过一些坑下面按模块说明字段设计思路和理由。3.1 用户表 t_user核心字段id、学号/工号、姓名、密码BCrypt加密存储、角色0普通用户、1管理员、性别、所在学院、专业班级、联系电话、邮箱、头像URL、信用分、状态0正常、1封禁、create_time、update_time、deleted逻辑删除。几个设计理由学号字段要加唯一索引因为校验身份时要用头像不存图片二进制只存URL图片文件上传到服务器本地目录或MinIO对象存储都行信用分是后面做评价和举报处理的基础初始给100分被举报核实扣分低于某个阈值禁止发布商品。逻辑删除字段非常关键用户注销、商品删除都走逻辑删除保留记录用于后台追溯和统计数据同时避免外键关联断裂的问题。3.2 商品表 t_goods核心字段id、用户id、标题、描述、原价、售价、成色9成新/8成新/有使用痕迹等、分类id、校区、楼栋、交易方式线下/邮寄/均可、图片主图URL、状态0待审核、1在售、2已下架、3已售出、4审核未通过、浏览数、收藏数、发布时间、下架时间。售价字段必须用DECIMAL(10,2)不能用Double/Float原因后面踩坑部分细说。状态这个字段看似只有五六个值实际上状态流转是整个系统最复杂的部分用户发布是0管理审核通过是1用户手动下架是2订单成交后是3审核驳回是4后续交易的并发问题都是围绕这个状态来的。3.3 交易订单表 t_order核心字段id、订单号唯一雪花算法生成、商品id、买家id、卖家id、成交价、订单状态0待确认、1已完成、2已取消、3退款/介入处理中、交易方式、预约时间、见面地点、买家留言、创建时间、完成时间。订单这块很多同学会犯一个错误直接套电商的“待付款、待发货、待收货、待评价”全链路。但校园闲置交易只在站内完成“意向确认”真正付款和交付都是线下完成的所以订单状态不需要“已付款”“已发货”这些节点而是“待确认买家发起、卖家同意——已完成双方在线下见面交易后由任意一方确认完成——已取消任意一方在确认前取消”。这样设计不仅贴合实际场景而且论文里能明确说“支付和物流不在本系统范围内这与系统定位有关”。3.4 辅助表收藏表 t_favoriteid、用户id、商品id、create_time做唯一联合索引(user_id, goods_id)防重复收藏。私信表 t_messageid、发送方id、接收方id、关联商品id可空、内容、发送时间、是否已读。这里可以做WebSocket在线聊天推送给系统加分不想做WebSocket就做轮询页面每3秒拉一次未读数也够用。举报表 t_reportid、举报人id、被举报对象类型商品/用户/评论、对象id、举报原因、举报描述、处理状态0待处理、1已处理、处理结果、处理时间。求购信息表 t_wantedid、用户id、标题、描述、期望价格、期望成色、分类id、状态0有效、1已达成、2已下架、发布时间。公告表 t_noticeid、标题、内容、类型、创建时间、是否置顶。轮播图表 t_bannerid、图片URL、跳转链接、排序、状态、创建时间。这套表直接画E-R图关系非常清楚用户1-N商品商品1-1订单这里在设计上让一个商品同时只能有一个有效订单防止一物多卖用户N-M收藏商品通过收藏表用户N-M私信关系。数据库设计章节的“表结构说明”就把这些字段的意义、索引、外键逻辑一一列出可以写很多页。数据库建表DDL片段节选CREATE TABLE t_goods ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 发布者id, title varchar(100) NOT NULL COMMENT 商品标题, description text COMMENT 商品描述, original_price decimal(10,2) DEFAULT NULL COMMENT 原价, price decimal(10,2) NOT NULL COMMENT 售价, condition_level tinyint(4) DEFAULT NULL COMMENT 成色 1-10, 10为全新, category_id bigint(20) DEFAULT NULL COMMENT 分类id, campus varchar(50) DEFAULT NULL COMMENT 校区, building varchar(50) DEFAULT NULL COMMENT 楼栋, deal_type tinyint(4) DEFAULT 0 COMMENT 交易方式 0线下 1邮寄 2均可, main_image varchar(255) DEFAULT NULL COMMENT 主图URL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待审核 1在售 2已下架 3已售出 4审核未通过, view_count int(11) DEFAULT 0, favorite_count int(11) DEFAULT 0, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted tinyint(1) DEFAULT 0, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_category_id (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;建表的两个细节字段类型上数字状态一律用tinyint不要用varchar存“上架”“下架”这种中文评论等可能含表情符号的字段表字符集统一用utf8mb4不要用utf8utf8mb3存不了emoji私信功能就会收到乱码。4. 商品和订单的状态机这块设计好了答辩时能讲十分钟状态机是我觉得这个系统里最容易被忽视但最值得展开设计的一环。它的价值在于所有状态流转都不是随意的一对一的合法路径被定死代码层面可以通过常量校验甚至状态模式来实现。论文里能单独开一节“系统状态流转设计”配合状态图说明是打分亮点。商品状态流转是这样设计的发布后进入“待审核(0)”——管理员审核通过进入“在售(1)”——管理员驳回回到“待审核(0)”或进入“审核未通过(4)”——“待审核”状态下用户可撤回变为“已下架(2)”——“在售”状态下用户主动下架变为“已下架(2)”——“在售”状态下商品被买家发起订单、且订单被卖家确认后商品直接变为“已售出(3)”——“已售出”状态不可再被上架。特别注意一个场景商品被买家A发起订单但卖家还没确认时商品应该仍然显示为“在售”还是“锁定”我的做法是引入一个“锁定标记”字段lock_flag订单发起时把商品lock_flag置为1但status保持“在售”其他人可以看到但不能发起订单避免多个买家同时对同一商品下单。这个字段在订单取消/超时后重置。这个设计的细节很值得在论文里写提问“一个商品同时被两个人下单怎么办”时能答上来。订单状态机的核心节点买家发起订单状态0待确认——卖家同意状态1待交易——任意一方在线下交易完成后确认状态1转为状态2已完成若卖家拒绝或买家取消则进入状态3已取消。另外给“已确认但线下未交付”加一个超时保护订单创建后24小时内未确认通过定时任务自动取消并把商品lock_flag恢复。代码层面可以写一个状态转换校验器private static final MapInteger, SetInteger ORDER_STATUS_TRANSITIONS new HashMap(); static { ORDER_STATUS_TRANSITIONS.put(0, new HashSet(Arrays.asList(1, 3))); ORDER_STATUS_TRANSITIONS.put(1, new HashSet(Arrays.asList(2, 3))); ORDER_STATUS_TRANSITIONS.put(2, Collections.emptySet()); ORDER_STATUS_TRANSITIONS.put(3, Collections.emptySet()); } public boolean canTransit(int from, int to) { return ORDER_STATUS_TRANSITIONS.getOrDefault(from, Collections.emptySet()).contains(to); }这样做的好处是后续新增状态比如“退款处理中”时只改这一个映射的地方就行了。接口层所有可能改变状态的接口先校验canTransit再执行update能防住绝大多数非法请求。5. 核心实现细节下单防超卖、Redis缓存、定时清超时订单5.1 下单接口的防超卖处理前面说了“一个商品同时只允许一个有效订单”怎么落地两个手段要配合数据库层面的锁和唯一性控制以及应用层的状态校验。最简单可靠的是用MySQL的SELECT ... FOR UPDATE把商品行锁住检查状态和lock_flag再做更新Transactional public boolean createOrder(Long goodsId, Long buyerId) { Goods goods goodsMapper.selectByIdForUpdate(goodsId); // 自定义SQL: select * from t_goods where id ? for update if (goods null || goods.getStatus() ! 1) { throw new BizException(商品不存在或不在售); } if (goods.getLockFlag() 1) { throw new BizException(商品已被其他买家锁定); } // 创建订单、锁定商品 goods.setLockFlag(1); goodsMapper.updateById(goods); orderMapper.insert(buildOrder(goods, buyerId)); return true; }有的同学担心FOR UPDATE性能这个场景并发量其实很低锁行的时间也就是几毫秒完全没问题。如果你想让论文里多一点亮点也可以讲乐观锁给t_goods加version字段在“锁定”操作时通过WHERE id? AND version?条件更新更新行数为0说明版本不对则重试或放弃。两种方案各有适用条件我当时是结合写的行锁保证事务内强一致version字段作为乐观锁兜底并展示在论文方案对比中。5.2 Redis缓存怎么用才不显得凑数很多毕设硬凑Redis就是给登录验证码存个值这说服力不太够。我在这系统里实际用到的Redis场景有四个验证码存储图形验证码/邮箱验证码key“captcha:{sessionId}”过期时间5分钟用Redis是因为它自带TTL不用自己写清理逻辑。热门商品缓存商品首页列表、热门推荐列表key“hot:goods:list”缓存10分钟用户在10分钟内多次访问首页走的是缓存而不是DB。这类缓存最怕缓存穿透查不到商品ID时要把空值也缓存一下或者做布隆过滤器论文里能写这个会加分。商品详情计数浏览数、收藏数先写Redis定时异步同步到MySQL避免每次页面刷新都更新数据库。登录Token黑名单JWT本身无状态但管理员封禁某个用户时要让TA立即失效把该用户的JWT uniqueId放进Redis黑名单拦截器每请求检查一次。5.3 超时订单的定时任务用Spring自带的Scheduled就够了Component public class OrderTimeoutTask { Autowired private OrderMapper orderMapper; Autowired private GoodsMapper goodsMapper; Scheduled(fixedDelay 60_000) public void autoCancelTimeoutOrders() { // 找出超过24小时仍在待确认状态且商品仍处于锁定状态的订单 ListOrder timeoutOrders orderMapper.selectTimeoutOrders(nowMinus24Hours()); for (Order order : timeoutOrders) { // 事务内执行改订单状态为已取消恢复商品lock_flag orderService.cancelOrder(order.getId(), 系统超时自动取消); } } }注意fixedDelay表示上一次执行完后隔1分钟再执行而不是fixedRate1分钟1次硬性调度避免任务本身执行时间过长导致的重复调度。多实例部署时记得用SchedulerLock加分布式锁不然两台机器同时跑就会重复取消订单。毕设场景一般单实例就行但这个知识点在答辩的时候提到会显得你考虑过生产环境问题。5.4 JWT登录拦截和RBAC权限后端定义一个拦截器处理Authorization头解析出userId和role放入ThreadLocal的UserContext里。凡是/api/user/**、/api/goods/**这些需要登录的路径拦截器里校验凡是/admin/**路径除了校验登录还要校验role管理员。特别注意跨域请求会先发送一个OPTIONS预检请求拦截器要放行OPTIONS并设置跨域响应头否则前端联调时好端端的接口突然报401很多同学查半天查不出来。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new NotLoginException(); } Claims claims JwtUtil.parse(token); Long userId claims.get(userId, Long.class); UserContext.set(userId, (Integer) claims.get(role)); return true; } }6. 论文那么厚工作量从哪来按章节倒推功能点和写作素材写论文时最愁的是“系统太简单字数凑不够”。我的建议是不要最后才来凑字一开始就按论文章节倒推功能设计让每个技术点都有对应的写作素材。论文第五章一般是“系统实现”你手头要有的素材包括每个核心功能模块的界面截图、核心代码片段不要贴大段完整代码贴关键逻辑、操作流程描述、涉及的接口设计可以用表格列出接口路径、请求方式、参数、返回说明。这些素材在开发过程中顺手整理不要等写论文时重新截。下面是通用论文结构对应的功能映射第一章绪论写校园二手交易的背景引用一些高校二手资源浪费、毕业生甩卖难的数据国内外研究现状可以写闲鱼、转转的二手模式再写国外Freecycle、Gumtree这类平台。注意不要编造文献实在找不到就写“综合各大主流平台的业务模式归纳”。第二章需求分析可行性分析技术、经济、操作三层、用户角色分析学生、教职工、管理员、功能性需求用用例图或用例表、非功能性需求性能、安全、易用性、可维护性。需求这章要跟第一章的功能清单完全对应不能需求里写了购物车实现里没有。第三章系统设计系统总体架构画一个简单的层次图展示层、业务层、数据层、功能模块图、数据库E-R图和表结构、关键业务状态机设计、接口设计。我前面讲的商品状态机、订单状态机、防超卖方案都放这一章。第四章系统实现按“登录注册、商品管理、交易订单、后台管理、站内信”几个模块写每个模块写清楚业务逻辑和关键代码。第五章系统测试功能测试用表格列测试用例用例编号、测试步骤、预期结果、实际结果性能测试可以写用JMeter或Postman压测商品列表接口在Redis缓存开启前后的QPS和响应时间对比。这个对比数据是你自己真跑的答辩老师问细节你也能答。如果想提升工作量推荐三个官方认定的“有用功能”一是用户信用分评价体系交易完成后互评差评扣分信用分影响商品发布数量上限二是个人闲置数据统计发布总数、成交总数、交易成功率、累计省下金额用ECharts画图表三是商品导出报表管理员端按分类/时间导出Excel用EasyExcel。这三个功能都贴近校园场景且实现成本不高论文里还能各写一节。7. 实测踩坑笔记Java开发者最容易栽的六个地方7.1 BigDecimal到底怎么传售价用BigDecimal但JSON序列化后前端拿到的可能是科学计数法“1.2E2”或者前端用Number类型丢失精度。我的做法是统一在BigDecimal字段上加JsonSerialize(using ToStringSerializer.class)让它输出字符串“120.00”前端展示直接用下单再转回BigDecimal。7.2 MyBatis Plus逻辑删除 唯一索引的冲突用户表给学号加了唯一索引又开了TableLogic逻辑删除。问题是用户A注销后deleted1再次注册同一学号时唯一索引判定重复插入失败。这个坑网上讨论很多我用的解决办法是唯一索引建成联合唯一(unique_no, deleted)删掉deleted1的记录才能再插入。建表时注意联合唯一索引让同一个学号最多一条有效记录deleted0历史删除记录可以无限保留。7.3 分页插件总是查不到第二页MyBatis Plus的老朋友了。分页插件不生效最常见原因是PaginationInnerInterceptor没配好或者新版要用MybatisPlusInterceptor而配置里还写的是旧版PaginationInterceptor。还有如果你在自定义SQL里写了“LIMIT”MP的分页插件不会自动拼接“LIMIT ? OFFSET ?”而是原始SQL直接爆掉。解决自定义分页SQL里不要自带LIMIT或者用MP内置的Page参数。7.4 跨域联调被OPTIONS拦死Spring Boot 后端配置CorsFilter但自定义 JWT 拦截器的顺序在 CorsFilter 之前时预检请求根本到不了CorsFilter就返回401。解决有两种拦截器里遇到OPTIONS直接放行上文代码就是这么处理或者更稳一点用WebMvcConfigurer去addCorsMappings并且让拦截器注册顺序晚于CORS配置。推荐第二种。而且注意别把Authorization头漏了allowedHeaders里要包含它。7.5 上传文件的MIME类型校验商品图片上传只检查Content-Type是“image/png”完全不够因为伪造Content-Type太容易了。还要校验文件头魔数PNG文件头89 50 4E 47JPEG文件头FF D8 FF可以在上传时读取文件前几个字节校验。另外上传目录不要放在项目resources里要把真实磁盘路径写在配置文件里重启不丢文件。如果你不想折腾对象存储本地磁盘一个静态资源映射配置足够演示。7.6 定时任务在开发环境跑了“奇奇怪怪”的效果开发时把Scheduled任务加上后经常会遇到每天凌晨零点执行统计本地测试时每次启动都来一遍数据不准还不好调试。我建议所有定时任务加一个手动触发接口/admin/task/run/{taskName}自动跑归自动跑手动触发用于联调论文测试章节也好写“管理员可手动触发统计任务”。7.7 时间字段的时区坑LocalDateTime直接序列化到前端经常差8个小时。统一在配置文件里设置spring.jackson.time-zoneGMT8以及数据库连接串加serverTimezoneAsia/Shanghai前后端时间格式就能对齐。这个坑很隐蔽一开始测接口“创建时间总是比现在慢8个小时”后来检查代码才想起来是连接串没带时区。8. 答辩前夜评委一定会问的七个问题答法我给你备好答辩是最多人心虚的环节。评委不一定把你所有代码看完但一定会问几个固定的“架构和设计”类问题。我把自己被问过、以及帮学弟模拟过的几个高频问题整理出来每个都给一个清晰的回答思路。问题一你这个系统跟闲鱼的区别是什么切入点是“校园场景”。要说清楚信任机制学号审核、交易方式线下为主、无物流、商品范围校园闲置、管理端校内管理员审核这四点最后补一句“闲鱼是综合C2C生态本系统面向封闭校园社区只做低频高信任交易”。这个问答几乎必问。问题二为什么用JWT不用Session答前后端分离部署后端可能需要横向扩展JWT无状态可以任意路由Session有状态扩展时要处理Session共享。但也要承认JWT有服务端无法主动吊销的缺陷所以系统里用Redis黑名单配合封禁功能。能说短板且能给出方案比只吹好话强。问题三商品并发下单怎么解决的把5.1的内容答出来顺手画一下“FOR UPDATE行锁 lock_flag”的执行流程再说乐观锁兜底。这个问题问到说明评委在考察你对数据库并发控制的理解。问题四为什么要用Redis缓存答验证码需要过期时间、热门商品列表降低DB压力、浏览计数减轻频繁写操作。再补一句缓存一致性方案先更新DB再删缓存设置过期兜底就很完整。问题五图片存储为什么不放数据库答二进制数据会增大数据库体积、拖慢备份和查询所以存本地磁盘/对象存储数据库只存URL。如果被追问“URL失效怎么办”就说后台做了文件校验部署时通过MD5比对检查文件完整性。问题六如果用户一直不确认交易怎么办答系统有超时保护订单超过24小时未确认定时任务自动取消并恢复商品锁定状态如果已经线下交易但忘记确认用户可在我的订单里主动确认或申请客服介入管理端可以人工修改状态。顺带把scheduler的代码逻辑演示一遍就行。问题七你的系统有哪些安全性设计把密码加密BCrypt、登录校验JWT拦截器、权限控制角色级别、SQL注入防护MyBatis预编译、XSS过滤后端统一做富文本清洗、文件上传魔数校验、防重复提交都列一遍。这里每一条你都能在代码里定位到具体位置那这题就是送分题。9. 演示现场最容易翻车的三个操作提前规避掉答辩现场演示不是给你展示代码的是展示“系统能跑、逻辑闭合、数据真实”。我见太多学弟因为演示翻了车这里讲三个必查项。第一演示数据不要用空库刚初始化的数据。提前往系统里录好10个以上商品分布在三四个人为账号下分类尽量全一些教材、电子产品、生活用品、运动器材订单里最好有一两单处于“已完成”一单正在“待确认”。这样演示时页面是丰富的评论聊天的界面也有内容可截。第二不要登录态过期。答辩前检查JWT的过期时间不要太短。现场录了新用户、传了图结果提交商品时Token过期页面直接跳登录节奏恨不得全乱。我建议答辩前统一用测试环境账号登录好且把Token过期时间设成8小时。第三数据库连接千万别断。很多同学在演示环境跟宿舍WiFi绑定教室WiFi一变IPMySQL连接池直接爆错误。答辩前把所有服务都跑在笔记本本地数据库也放本地连不上外网也没关系这样最稳。轮播图、商品图片都本地化不要依赖外网图床。如果你能把上面这些流程都过一遍系统本身的完成度、论文的深度、答辩的临场发挥就都闭环了。最后讲点我个人的感受这套系统最花时间的不是CRUD是需求和状态机。把“校园交易”这件事想明白了表设计、代码结构、论文章节是一环扣一环顺下来的。如果你正在为选题发愁或者做了一半发现功能四处漏风回过头来把需求和状态流转再捋一遍八成能救回来。至于系统上线后的运营那些二手交易促成率、用户留存的问题就是另一个“毕业后”的故事了。