尧图网页设计 
简介面向计算机专业学生与开发者的校园二手交易平台设计文档基于Java语言采用SSMSpring、SpringMVC、MyBatis整合框架、Vue前端及MySQL数据库围绕管理员、普通用户、商家三种角色覆盖商品审核、在线购买、购物车管理、订单管理等完整业务模块。文档从课题背景、系统分析到技术实现均有涉及可帮助读者理解校园二手交易场景下的需求整理、架构设计和数据库方案其中管理员可审核商品并管理用户商家可发布商品和销售订单普通用户则可完成在线购物与订单管理角色权限与业务流程描述较完整。资源为单个docx文件大小约3.45MB内容为完整的Word版设计文档包含中英文摘要、关键词、目录、系统分析等章节结构清晰便于直接查阅和二次编辑。已有33人学习适合毕业设计、课程设计或项目启动前参考可作为搭建同类平台和撰写技术文档的模板。1. 项目选题为什么我推荐用Java做校园二手交易平台这个标题看起来很“毕设”但说实话校园二手交易平台在 Java 全栈项目里属于非常经典的一类。它不像电商系统那样需要处理海量并发、复杂的支付清结算也不像 ERP 那样堆满业务单据它的复杂度刚好卡在“能体现完整开发能力”和“一个人能做完”之间非常适合用来作为课程设计或毕业设计的选题。先把这个项目到底在解决什么问题说清楚。校园里的二手交易一直存在但闲鱼、转转这类平台面向全社会用户太杂、信任成本高而且发布和沟通链路比较重。校园场景的特点是范围小、人群相对固定、线下见面方便所以一个轻量的、只面向本校学生的交易平台反而能切中真实需求。你不需要做担保支付不需要做复杂的物流对接核心就是让卖家和买家能在平台内完成“发布—发现—沟通—成交—评价”这条链路。从技术角度看这个项目覆盖的知识点非常完整基于 Servlet 或 Spring Boot 的后端接口开发、MySQL 表设计、文件上传、登录鉴权、分页查询、简单的状态机流转。如果你是打算拿它当毕设这样的技术栈足以支撑论文里的“需求分析—系统设计—数据库设计—系统实现—测试”全套结构如果你是想靠它找工作把项目里的某几个点比如登录鉴权、订单状态流转、防重复提交讲透了也能在面试里加分。选型上我用的是 Spring Boot 作为主框架。现在的校园项目再从头写 SSHStruts Spring Hibernate已经没什么意义了Spring Boot 内置 Tomcat、自动配置、起步依赖能把大量精力从“配置环境”转移到“写业务逻辑”上这也是真实企业里最主流的 Java Web 开发方式。2. 整体设计思路与技术选型解析2.1 技术栈选择的真实考量后端用 Java Spring Boot前端我建议搭配 Thymeleaf 服务端渲染加 Bootstrap而不是一上来就搞 Vue 前后端分离。原因很简单校园二手交易平台的核心是业务逻辑和数据库设计不是前端工程化。用 Thymeleaf 做页面模板数据在服务端直接渲染整个项目的代码量、调试难度、答辩时的讲解难度都会低一个档次。如果你已有 Vue 基础也可以做成前后端分离但需要额外处理跨域、Token 校验、接口文档周期会长不少。数据库用 MySQLORM 层我选 MyBatis-Plus。MyBatis-Plus 的 BaseMapper 直接提供单表增删改查分页插件一行配置就能用可以省掉大量重复的 XML 编写工作。有的同学喜欢用 JPA但 JPA 在一些复杂查询上反而更绕MyBatis 系在国内企业的使用率也明显更高。文件存储不需要接 OSS直接用本地磁盘存储加虚拟路径映射就够了。项目级别的东西阿里云 OSS 还要实名、配 Bucket、写 SDK 调用本地存储一个 MultipartFile.transferTo 就完事答辩时也能清楚地说明存储结构。2.2 角色与权限模型三类用户怎么划分这个系统的用户我分成三类普通用户、管理员、超级管理员。普通用户就是学生能注册登录、发布商品、编辑下架自己的商品、收藏、下单、留言、评价。管理员负责审核商品、管理用户、处理举报。超级管理员负责给管理员分配权限、查看全站统计。权限控制不能只靠前端隐藏按钮后端必须做拦截。我使用 Spring Boot 拦截器加自定义注解的方式实现定义一个RequireLogin注解标注在 Controller 方法上拦截器里检查当前 Session 中是否有用户再定义一个RequireAdmin注解标注管理员接口。这样整个权限体系只要维护注解和拦截器两个地方比每个接口里手写 if 判断要优雅得多。这里有个关键设计用户表里要有一个role字段区分三类用户但前端的页面是共用的只是根据角色不同显示不同入口。不要把“用户表”和“管理员表”分开建那会让登录逻辑变得非常啰嗦也不符合实际项目的表设计思路。2.3 页面结构与核心闭环页面不用多够用、闭环清晰即可登录注册页首页商品列表、分类筛选、搜索商品详情页商品信息、卖家信息、购买/收藏/留言发布商品页个人中心我的发布、我的购买、我的收藏、我的留言管理后台商品审核、用户管理、举报处理核心闭环是“发布—浏览—购买—确认收货—互评”。值得留意的是二手商品交易和有库存电商不一样每件商品只有 1 件所以不需要“购物车”也不需要“库存扣减”的复杂设计——它的交易状态流转成为系统设计中的重点后面我在第三节专门展开。3. 核心业务模块实现与关键设计3.1 状态机二手交易最核心的业务逻辑商品状态和订单状态是这个项目最值得花时间设计的地方也是答辩时很加分的部分。商品状态我用五个状态待审核、在售、已预订、已售出、已下架。用户发布商品后先进入待审核管理员审核通过才在首页展示。当买家下单但还没付款或还没线下交易时商品变为已预订避免其他人再下单交易完成后变为已售出用户主动下架就变为已下架。订单状态我用四个状态待交易、已完成、已取消、已退款。第二步中下单后不是立刻扣钱因为校园二手交易大多是当面交易或私下转账。订单的作用是“锁定意向”和“记录交易凭证”这个定位很重要。买家下单后卖家能看到订单双方约定时间地点交易完成后双方确认订单完成之后可以进入评价环节。转移条件必须写清楚待审核 → 在售管理员通过待审核 → 已下架管理员拒绝 或 用户主动撤回在售 → 已预订买家下单已预订 → 已售出确认交易完成已预订 → 在售买家取消订单在售 → 已下架用户主动操作在每个状态变更时数据库操作必须加事务控制比如下单时同时更新商品状态为已预订如果订单插入成功但商品更新失败事务要回滚。先用Transactional注解解决这个问题答辩时如果能说出“为什么需要事务”就能加分。3.2 数据库表设计六张核心表就够了不要设计太多表这个项目六张核心表完全够用user用户表含 username、password、role、avatar、contactcategory分类表含 category_name、sort_ordergoods商品表含 goods_name、description、price、cover_image、images、status、seller_id、category_id、created_timeorders订单表含 order_no、goods_id、buyer_id、seller_id、status、created_time、finish_timefavorites收藏表含 user_id、goods_id、created_timemessage留言表含 goods_id、from_user_id、to_user_id、content、reply_content、created_time商品表里的images我建议存多图路径用逗号分隔比如/upload/xxx1.jpg,/upload/xxx2.jpg。很多人喜欢为图片建一张子表不是不行但对这个项目来说没有必要。多图路径用逗号分隔读取时用 split 拆一下就能得到图片列表简单高效。价格字段必须用DECIMAL(10,2)不要用 DOUBLE。Java 里的 float/double 做金额计算会有精度问题0.1 0.2 并不等于 0.3这在需要展示和比较价格的场景下非常尴尬。虽然在校园二手交易里不涉及复杂金融计算但这是一个良好习惯面试时被问到“金额用什么类型”也能答得上。3.3 用户登录与密码安全登录功能不要只做一个简单的密码比对至少要做到两点密码加密存储、登录状态校验。密码加密我使用 BCrypt。不要用 MD5MD5 已经能被暴力破解而且同样的密码会生成相同的哈希值风险较高。BCrypt 每次生成的哈希值都不一样但matches方法可以校验Spring Security 里直接有 BCrypt 实现单独引入一个类也可以用。登录状态我用 Session 存储用户对象。用户登录成功后session.setAttribute(loginUser, user)拦截器里检查这个属性是否存在。Session 方案在这种单体、服务端渲染的项目里比 JWT 更简单浏览器自动维持会话不需要额外处理 Token 的存储和过期问题。这里有一个很多人会犯的错误Session 里应该存一个轻量对象比如只有 id、username、role 的对象不要在每次登录时把整个 User 对象塞进去。因为用户可能修改头像、联系方式Session 里的旧数据如果不更新页面显示的会是过时信息。正确做法是拦截器里每次请求时根据 Session 中的 userId 重新查询数据库保证拿到最新数据代价是每次请求多一次查询但换来数据一致性很划算。3.4 商品发布与图片上传发布商品页面要处理的信息商品名称、描述、分类、价格、成色说明、联系方式、上传图片。图片上传有四个关键点。第一只接收图片格式通过文件后缀名和 MIME 类型双重校验第二限制文件大小比如单张不超过 5MB用 MultipartFile 的getSize()判断第三文件重命名用 UUID 加时间戳生成新文件名避免中文名乱码和重复第四存储路径要按日期分目录比如/files/2024/11/23/uuid.jpg这样后续按时间清理旧文件很方便。Spring Boot 里要把上传目录映射为静态资源访问路径否则浏览器访问不了图片spring: web: resources: static-locations: file:${upload.path},classpath:/static/同时设置单个文件大小限制spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB不配置这段的话文件超过 1MB 就会直接报 500非常坑。4. 实操过程中的问题排查与经验总结4.1 我踩过的四个坑希望你避开第一个坑日期格式化问题。MySQL 的 datetime 字段通过 MyBatis 查出来默认直接 JSON 序列化Thymeleaf 里显示出来可能是2024-11-23T10:30:00这种带 T 的格式。前端页面显示时间要么在实体类上写JsonFormat(pattern yyyy-MM-dd HH:mm:ss)要么在模板里用工具类格式化。更简单的方案是查询时直接用 MySQL 的DATE_FORMAT函数转成字符串比如DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s)返回的字段类型就是 String一个坑都不用踩。第二个坑MyBatis-Plus 分页查不出数据。MyBatis-Plus 3.x 需要显式配置分页插件不配置的情况下分页查询会直接查全表而且不报错导致页面显示和预期不一致。正确配置Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }第三个坑图片删除不彻底。用户删除商品时如果在数据库里删了记录但没删磁盘上的图片文件时间长了服务器会积攒大量无用文件。需要在删除商品时同时删除对应图片文件String cover goods.getCoverImage(); if (StringUtils.hasText(cover)) { File file new File(uploadPath cover.replace(/files/, )); if (file.exists()) { file.delete(); } }第四个坑价格显示精度问题。如果使用 DOUBLE 类型存价格页面显示88.00000001这种奇怪数字是很常见的。我在数据库表结构里严格使用 DECIMAL实体类中用BigDecimal接收前端格式化时用#numbers.formatDecimal(price, 1, 2)三管齐下价格显示才稳定。4.2 高频问题排查速查表现象可能原因解决思路上传图片后 404 无法访问静态资源映射未配置检查spring.web.resources.static-locations配置图片上传超过 1MB 就报错未配置 multipart 大小限制添加max-file-size和max-request-size配置分页查询一直查全表MyBatis-Plus 分页插件未注册添加PaginationInnerInterceptor配置商品编辑后状态错乱状态字段没有做校验在修改方法里先判断当前状态是否允许下一步操作部署到 Linux 后图片路径报错Windows 和 Linux 路径分隔符不同使用File.separator拼接路径避免硬编码/或\多个用户同时下单同一商品并发问题对 goods 状态做乐观锁/悲观锁控制或下单时用条件更新校验状态4.3 并发下单的一个实用处理方案校园二手平台虽然并发量不高但“两个人同时看中一件商品并同时下单”是完全可能发生的。最简单可靠的处理方法是在更新商品状态时加上条件判断boolean success updateById(new Goods().setId(goodsId).setStatus(2), new LambdaQueryWrapperGoods() .eq(Goods::getId, goodsId) .eq(Goods::getStatus, 1)); // 只有状态为“在售”时才能更新这样即使两个请求同时到达数据库层面只有一个 update 会生效。第二个请求因为 where 条件不满足更新影响行数为 0代码里根据影响行数判断是否下单成功直接提示用户“商品已被预订”。这是在项目体量下最实用、成本最低的并发控制方案。5. 写在最后的一些经验把这套系统从零开始做完我的个人感受是校园二手交易平台的难点从来不是某项技术有多深而是把一堆基础技术组合得恰到好处。状态机设计要严谨不能让商品从“待审核”直接跳到“已售出”数据库设计要克制不要为了设计而设计出一堆没用的表页面逻辑要闭环用户发布商品后能知道去哪看进度下单后能知道去哪联系卖家。如果你正在做这个题目建议把精力优先放在订单状态流转和权限控制上这两个点在写论文和答辩时最容易展开也最加分。开发时先跑通核心链路——注册登录、发布商品、下单、确认完成再去补收藏、留言、搜索等边缘功能顺序不要搞反。另外一个小技巧开发时可以给所有接口设计成 RESTful 风格比如POST /api/goods发布、PUT /api/goods/{id}/offline下架、GET /api/goods?page1列表。即使你用的是 Thymeleaf 渲染接口路径也按这个风格来设计后续如果要改成前后端分离只需要把 Controller 的返回值从 ModelAndView 改为 JSON业务逻辑完全不用动。这样既完成了毕设要求又为自己留了一条继续迭代的路。本文还有配套的精品资源点击获取 基于Spring Boot的校园二手交易平台设计与实现核心要点
简介面向计算机专业学生与开发者的校园二手交易平台设计文档基于Java语言采用SSMSpring、SpringMVC、MyBatis整合框架、Vue前端及MySQL数据库围绕管理员、普通用户、商家三种角色覆盖商品审核、在线购买、购物车管理、订单管理等完整业务模块。文档从课题背景、系统分析到技术实现均有涉及可帮助读者理解校园二手交易场景下的需求整理、架构设计和数据库方案其中管理员可审核商品并管理用户商家可发布商品和销售订单普通用户则可完成在线购物与订单管理角色权限与业务流程描述较完整。资源为单个docx文件大小约3.45MB内容为完整的Word版设计文档包含中英文摘要、关键词、目录、系统分析等章节结构清晰便于直接查阅和二次编辑。已有33人学习适合毕业设计、课程设计或项目启动前参考可作为搭建同类平台和撰写技术文档的模板。1. 项目选题为什么我推荐用Java做校园二手交易平台这个标题看起来很“毕设”但说实话校园二手交易平台在 Java 全栈项目里属于非常经典的一类。它不像电商系统那样需要处理海量并发、复杂的支付清结算也不像 ERP 那样堆满业务单据它的复杂度刚好卡在“能体现完整开发能力”和“一个人能做完”之间非常适合用来作为课程设计或毕业设计的选题。先把这个项目到底在解决什么问题说清楚。校园里的二手交易一直存在但闲鱼、转转这类平台面向全社会用户太杂、信任成本高而且发布和沟通链路比较重。校园场景的特点是范围小、人群相对固定、线下见面方便所以一个轻量的、只面向本校学生的交易平台反而能切中真实需求。你不需要做担保支付不需要做复杂的物流对接核心就是让卖家和买家能在平台内完成“发布—发现—沟通—成交—评价”这条链路。从技术角度看这个项目覆盖的知识点非常完整基于 Servlet 或 Spring Boot 的后端接口开发、MySQL 表设计、文件上传、登录鉴权、分页查询、简单的状态机流转。如果你是打算拿它当毕设这样的技术栈足以支撑论文里的“需求分析—系统设计—数据库设计—系统实现—测试”全套结构如果你是想靠它找工作把项目里的某几个点比如登录鉴权、订单状态流转、防重复提交讲透了也能在面试里加分。选型上我用的是 Spring Boot 作为主框架。现在的校园项目再从头写 SSHStruts Spring Hibernate已经没什么意义了Spring Boot 内置 Tomcat、自动配置、起步依赖能把大量精力从“配置环境”转移到“写业务逻辑”上这也是真实企业里最主流的 Java Web 开发方式。2. 整体设计思路与技术选型解析2.1 技术栈选择的真实考量后端用 Java Spring Boot前端我建议搭配 Thymeleaf 服务端渲染加 Bootstrap而不是一上来就搞 Vue 前后端分离。原因很简单校园二手交易平台的核心是业务逻辑和数据库设计不是前端工程化。用 Thymeleaf 做页面模板数据在服务端直接渲染整个项目的代码量、调试难度、答辩时的讲解难度都会低一个档次。如果你已有 Vue 基础也可以做成前后端分离但需要额外处理跨域、Token 校验、接口文档周期会长不少。数据库用 MySQLORM 层我选 MyBatis-Plus。MyBatis-Plus 的 BaseMapper 直接提供单表增删改查分页插件一行配置就能用可以省掉大量重复的 XML 编写工作。有的同学喜欢用 JPA但 JPA 在一些复杂查询上反而更绕MyBatis 系在国内企业的使用率也明显更高。文件存储不需要接 OSS直接用本地磁盘存储加虚拟路径映射就够了。项目级别的东西阿里云 OSS 还要实名、配 Bucket、写 SDK 调用本地存储一个 MultipartFile.transferTo 就完事答辩时也能清楚地说明存储结构。2.2 角色与权限模型三类用户怎么划分这个系统的用户我分成三类普通用户、管理员、超级管理员。普通用户就是学生能注册登录、发布商品、编辑下架自己的商品、收藏、下单、留言、评价。管理员负责审核商品、管理用户、处理举报。超级管理员负责给管理员分配权限、查看全站统计。权限控制不能只靠前端隐藏按钮后端必须做拦截。我使用 Spring Boot 拦截器加自定义注解的方式实现定义一个RequireLogin注解标注在 Controller 方法上拦截器里检查当前 Session 中是否有用户再定义一个RequireAdmin注解标注管理员接口。这样整个权限体系只要维护注解和拦截器两个地方比每个接口里手写 if 判断要优雅得多。这里有个关键设计用户表里要有一个role字段区分三类用户但前端的页面是共用的只是根据角色不同显示不同入口。不要把“用户表”和“管理员表”分开建那会让登录逻辑变得非常啰嗦也不符合实际项目的表设计思路。2.3 页面结构与核心闭环页面不用多够用、闭环清晰即可登录注册页首页商品列表、分类筛选、搜索商品详情页商品信息、卖家信息、购买/收藏/留言发布商品页个人中心我的发布、我的购买、我的收藏、我的留言管理后台商品审核、用户管理、举报处理核心闭环是“发布—浏览—购买—确认收货—互评”。值得留意的是二手商品交易和有库存电商不一样每件商品只有 1 件所以不需要“购物车”也不需要“库存扣减”的复杂设计——它的交易状态流转成为系统设计中的重点后面我在第三节专门展开。3. 核心业务模块实现与关键设计3.1 状态机二手交易最核心的业务逻辑商品状态和订单状态是这个项目最值得花时间设计的地方也是答辩时很加分的部分。商品状态我用五个状态待审核、在售、已预订、已售出、已下架。用户发布商品后先进入待审核管理员审核通过才在首页展示。当买家下单但还没付款或还没线下交易时商品变为已预订避免其他人再下单交易完成后变为已售出用户主动下架就变为已下架。订单状态我用四个状态待交易、已完成、已取消、已退款。第二步中下单后不是立刻扣钱因为校园二手交易大多是当面交易或私下转账。订单的作用是“锁定意向”和“记录交易凭证”这个定位很重要。买家下单后卖家能看到订单双方约定时间地点交易完成后双方确认订单完成之后可以进入评价环节。转移条件必须写清楚待审核 → 在售管理员通过待审核 → 已下架管理员拒绝 或 用户主动撤回在售 → 已预订买家下单已预订 → 已售出确认交易完成已预订 → 在售买家取消订单在售 → 已下架用户主动操作在每个状态变更时数据库操作必须加事务控制比如下单时同时更新商品状态为已预订如果订单插入成功但商品更新失败事务要回滚。先用Transactional注解解决这个问题答辩时如果能说出“为什么需要事务”就能加分。3.2 数据库表设计六张核心表就够了不要设计太多表这个项目六张核心表完全够用user用户表含 username、password、role、avatar、contactcategory分类表含 category_name、sort_ordergoods商品表含 goods_name、description、price、cover_image、images、status、seller_id、category_id、created_timeorders订单表含 order_no、goods_id、buyer_id、seller_id、status、created_time、finish_timefavorites收藏表含 user_id、goods_id、created_timemessage留言表含 goods_id、from_user_id、to_user_id、content、reply_content、created_time商品表里的images我建议存多图路径用逗号分隔比如/upload/xxx1.jpg,/upload/xxx2.jpg。很多人喜欢为图片建一张子表不是不行但对这个项目来说没有必要。多图路径用逗号分隔读取时用 split 拆一下就能得到图片列表简单高效。价格字段必须用DECIMAL(10,2)不要用 DOUBLE。Java 里的 float/double 做金额计算会有精度问题0.1 0.2 并不等于 0.3这在需要展示和比较价格的场景下非常尴尬。虽然在校园二手交易里不涉及复杂金融计算但这是一个良好习惯面试时被问到“金额用什么类型”也能答得上。3.3 用户登录与密码安全登录功能不要只做一个简单的密码比对至少要做到两点密码加密存储、登录状态校验。密码加密我使用 BCrypt。不要用 MD5MD5 已经能被暴力破解而且同样的密码会生成相同的哈希值风险较高。BCrypt 每次生成的哈希值都不一样但matches方法可以校验Spring Security 里直接有 BCrypt 实现单独引入一个类也可以用。登录状态我用 Session 存储用户对象。用户登录成功后session.setAttribute(loginUser, user)拦截器里检查这个属性是否存在。Session 方案在这种单体、服务端渲染的项目里比 JWT 更简单浏览器自动维持会话不需要额外处理 Token 的存储和过期问题。这里有一个很多人会犯的错误Session 里应该存一个轻量对象比如只有 id、username、role 的对象不要在每次登录时把整个 User 对象塞进去。因为用户可能修改头像、联系方式Session 里的旧数据如果不更新页面显示的会是过时信息。正确做法是拦截器里每次请求时根据 Session 中的 userId 重新查询数据库保证拿到最新数据代价是每次请求多一次查询但换来数据一致性很划算。3.4 商品发布与图片上传发布商品页面要处理的信息商品名称、描述、分类、价格、成色说明、联系方式、上传图片。图片上传有四个关键点。第一只接收图片格式通过文件后缀名和 MIME 类型双重校验第二限制文件大小比如单张不超过 5MB用 MultipartFile 的getSize()判断第三文件重命名用 UUID 加时间戳生成新文件名避免中文名乱码和重复第四存储路径要按日期分目录比如/files/2024/11/23/uuid.jpg这样后续按时间清理旧文件很方便。Spring Boot 里要把上传目录映射为静态资源访问路径否则浏览器访问不了图片spring: web: resources: static-locations: file:${upload.path},classpath:/static/同时设置单个文件大小限制spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB不配置这段的话文件超过 1MB 就会直接报 500非常坑。4. 实操过程中的问题排查与经验总结4.1 我踩过的四个坑希望你避开第一个坑日期格式化问题。MySQL 的 datetime 字段通过 MyBatis 查出来默认直接 JSON 序列化Thymeleaf 里显示出来可能是2024-11-23T10:30:00这种带 T 的格式。前端页面显示时间要么在实体类上写JsonFormat(pattern yyyy-MM-dd HH:mm:ss)要么在模板里用工具类格式化。更简单的方案是查询时直接用 MySQL 的DATE_FORMAT函数转成字符串比如DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s)返回的字段类型就是 String一个坑都不用踩。第二个坑MyBatis-Plus 分页查不出数据。MyBatis-Plus 3.x 需要显式配置分页插件不配置的情况下分页查询会直接查全表而且不报错导致页面显示和预期不一致。正确配置Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }第三个坑图片删除不彻底。用户删除商品时如果在数据库里删了记录但没删磁盘上的图片文件时间长了服务器会积攒大量无用文件。需要在删除商品时同时删除对应图片文件String cover goods.getCoverImage(); if (StringUtils.hasText(cover)) { File file new File(uploadPath cover.replace(/files/, )); if (file.exists()) { file.delete(); } }第四个坑价格显示精度问题。如果使用 DOUBLE 类型存价格页面显示88.00000001这种奇怪数字是很常见的。我在数据库表结构里严格使用 DECIMAL实体类中用BigDecimal接收前端格式化时用#numbers.formatDecimal(price, 1, 2)三管齐下价格显示才稳定。4.2 高频问题排查速查表现象可能原因解决思路上传图片后 404 无法访问静态资源映射未配置检查spring.web.resources.static-locations配置图片上传超过 1MB 就报错未配置 multipart 大小限制添加max-file-size和max-request-size配置分页查询一直查全表MyBatis-Plus 分页插件未注册添加PaginationInnerInterceptor配置商品编辑后状态错乱状态字段没有做校验在修改方法里先判断当前状态是否允许下一步操作部署到 Linux 后图片路径报错Windows 和 Linux 路径分隔符不同使用File.separator拼接路径避免硬编码/或\多个用户同时下单同一商品并发问题对 goods 状态做乐观锁/悲观锁控制或下单时用条件更新校验状态4.3 并发下单的一个实用处理方案校园二手平台虽然并发量不高但“两个人同时看中一件商品并同时下单”是完全可能发生的。最简单可靠的处理方法是在更新商品状态时加上条件判断boolean success updateById(new Goods().setId(goodsId).setStatus(2), new LambdaQueryWrapperGoods() .eq(Goods::getId, goodsId) .eq(Goods::getStatus, 1)); // 只有状态为“在售”时才能更新这样即使两个请求同时到达数据库层面只有一个 update 会生效。第二个请求因为 where 条件不满足更新影响行数为 0代码里根据影响行数判断是否下单成功直接提示用户“商品已被预订”。这是在项目体量下最实用、成本最低的并发控制方案。5. 写在最后的一些经验把这套系统从零开始做完我的个人感受是校园二手交易平台的难点从来不是某项技术有多深而是把一堆基础技术组合得恰到好处。状态机设计要严谨不能让商品从“待审核”直接跳到“已售出”数据库设计要克制不要为了设计而设计出一堆没用的表页面逻辑要闭环用户发布商品后能知道去哪看进度下单后能知道去哪联系卖家。如果你正在做这个题目建议把精力优先放在订单状态流转和权限控制上这两个点在写论文和答辩时最容易展开也最加分。开发时先跑通核心链路——注册登录、发布商品、下单、确认完成再去补收藏、留言、搜索等边缘功能顺序不要搞反。另外一个小技巧开发时可以给所有接口设计成 RESTful 风格比如POST /api/goods发布、PUT /api/goods/{id}/offline下架、GET /api/goods?page1列表。即使你用的是 Thymeleaf 渲染接口路径也按这个风格来设计后续如果要改成前后端分离只需要把 Controller 的返回值从 ModelAndView 改为 JSON业务逻辑完全不用动。这样既完成了毕设要求又为自己留了一条继续迭代的路。本文还有配套的精品资源点击获取