尧图网站建设 
简介在Java后端开发中SpringBoot凭借自动配置机制大幅降低了环境搭建成本已成为构建企业级应用的主流框架。而校园二手交易平台作为典型的业务闭环项目天然覆盖用户认证、商品状态机、订单并发控制等核心场景非常适合用来理解框架原理与工程实践的配合。围绕这一主题文章从业务模块拆分出发梳理了用户、商品、交易三大核心域的表结构设计方法强调了价格用分存储、状态流转、事务边界等细节同时深入解析了基于乐观锁的防超卖下单逻辑以及JWT鉴权、文件上传、Docker部署等落地技术。对于正在准备毕业设计或希望提升SpringBoot实战能力的开发者这套完整方案既提供了可复用的数据库设计方法论也给出了从源码到可运行系统的避坑指南。 做毕设选题的时候十个Java方向的人里有九个会刷到“校园二手交易平台”这句话毫不夸张。但真正把源码下载下来能顺利跑起来、还能跟面试官讲清楚技术点的人十个里未必有一个。我做过一套基于SpringBoot的校园二手交易平台源码和数据库设计都完整整理过这中间踩了不少坑——SpringBoot版本兼容、MySQL表结构反复推倒重来、并发下单一不小心就超卖。这篇文章就把这套项目的经验从头梳理一遍不堆砌源码文件而是把模块划分、数据库设计、核心代码、部署坑点以及面试怎么答都讲透。无论你是刚学完Java基础想找项目练手还是准备用SpringBoot做毕业设计或者想从“会抄代码”进步到“能讲设计”这篇都值得认真看完。1. 为什么这个项目比“合租系统”“博客系统”更适合做Java练手项目1.1 校园二手交易的业务闭环决定了它的技术含量很多人选毕设题目时会考虑图书管理系统、博客系统、在线商城。这些系统确实简单但做完之后你会发现它们大多只是“多个表的CRUD”没有多少业务逻辑可讲。校园二手交易平台不一样它有自己的完整业务闭环学生注册后进行校园身份认证认证通过后可以发布闲置买家通过搜索、分类、收藏找到商品买卖双方经过站内聊天沟通细节买家下单后走站内余额模拟支付卖家发货、买家确认收货交易完成后双方可以互相评价如果出现问题还有举报和申诉流程管理员在后端进行商品审核、用户封禁、数据统计。这套流程决定了项目不是一堆孤立的表而是各个模块相互咬合的状态流转。比如商品不是删掉就消失而是有草稿、待审核、在售、预订、已售、强制下架的状态路径订单不是简单的insert而是先检查商品是否在售再乐观锁更新商品状态最后创建订单、扣减余额。这些逻辑写下来才是真正的“业务开发”。1.2 为什么要选SpringBootMyBatis-Plus这套组合选型的理由很多人答不上来。我的看法是SpringBoot的价值不是“快”而是它通过自动配置把环境差异收敛掉了。你在A机器上能跑换到B机器也能跑这对训练项目和实际交付太重要了。MyBatis-Plus把单表CRUD封装好了写起来比原生MyBatis少很多代码但它不是万能药像订单状态变更、库存扣减这种强一致性的写操作我都是写自定义SQL加乐观锁完全依赖BaseMapper是不合适的。我在这套项目里的推荐组合是SpringBoot 2.7.18 JDK 8 MySQL 8.0 MyBatis-Plus 3.5.3 Redis MinIO JWT。这套组合偏保守但稳定。后面章节我会专门说为什么不要一上来就追SpringBoot 3.x。2. 模块拆解先画清楚“人、货、单”三个核心域2.1 用户域不是简单地建一张user表用户模块最容易被做成一张只包含账号密码的user表我见过很多半成品就是这么干的。但校园二手平台有个特殊点用户需要证明自己是该校学生。于是在user表外我还设计了一张student_certification表用来存学号、姓名、所在院系、学生卡图片URL、认证状态。user表本身只放通用登录字段认证信息单独放原因是认证是一次性的低频操作拆开既能减少user表宽度也方便后台审核时只查认证表。user表核心字段id、username、password、nickname、avatar、phone、role0普通用户1管理员、status0禁用1正常、points信誉积分、create_time、update_time。密码存的是BCrypt加密后的字符串不是明文。这里有一个容易被忽略的点用户状态和登录逻辑要联动。如果账号被管理员禁用登录时不能只查用户名和密码还要校验status字段否则被处罚的用户依然可以正常登录。2.2 商品域发布到下架的完整状态机商品域的灵魂是状态。如果你的goods表里只有一个status字段但代码里没有一套状态流转逻辑那和普通文章表没有区别。我的状态设计为0草稿、1待审核、2在售、3预订中、4已售出、5下架、6管理员强制下架。为什么要有待审核因为不是所有学生都会规范发布商品后台管理员需要审核图片和标题防止出现违规品类。为什么要区分“预订中”和“已售出”因为线下交易存在“我先预订然后当面交付”的环节没有这个状态用户并发下单就控制不住。商品表字段包括id、user_id发布者、category_id、title、description、price单位分、original_price、quality成色、image_urlsJSON数组存图集、status、stock_version乐观锁版本号、view_count、create_time、update_time。价格我建议统一用“分”来表示不要用double否则订单金额计算会出现浮点误差这是个老生常谈但很容易踩的坑。2.3 交易域二手交易不是标准电商订单是所有模块里最容易出错的。二手交易和标准电商最大的差异是库存永远是1不允许超卖。标准电商可以扣减库存二手场景则应该是“下单即锁定商品”成功创建订单后商品状态从在售变为预订中其他人不能再下单。所以order表不能单纯当作订单记录表它实际承担了商品状态的“触发器”。订单表字段id、order_no、goods_id、buyer_id、seller_id、amount单位分、status0待支付1待发货2待收货3已完成4退款中5已关闭、pay_type0站内余额1线下交付、pay_time、deliver_time、receive_time、close_time、remark、create_time。另外还要一张trade_record表用来记录每次余额扣减和收入增加类似流水账对账和排查问题都用得上。3. 数据库设计9张核心表4张扩展表表和表之间的业务逻辑要能讲明白3.1 核心表的结构设计与建表SQL数据库设计不能一上来就建表而是先把业务对象拆成“主表子表状态流水”四个层次。以订单为例orders是主表记录一次交易的核心内容订单操作记录是流水表记录状态变更历史如果涉及退款还要有refund_record表。下表是我归纳出的核心表清单表名职责关键字段user账号登录与基本信息username、password、role、statusstudent_certification学生认证资料user_id、student_no、campus_card_url、auth_statusgoods_category商品分类name、parent_id、sortgoods商品信息user_id、category_id、status、stock_versiongoods_image商品图片goods_id、url、sortorders订单主表order_no、goods_id、buyer_id、seller_id、statustrade_record余额流水user_id、type、amount、balance_before、balance_afterfavorite收藏user_id、goods_id、create_timemessage站内私信from_user_id、to_user_id、content、is_read这里给出goods表的建表SQL注意索引和注释CREATE TABLE goods ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 发布者ID, category_id bigint(20) DEFAULT NULL COMMENT 分类ID, title varchar(120) NOT NULL COMMENT 标题, description text COMMENT 描述, price bigint(20) NOT NULL COMMENT 价格单位分, original_price bigint(20) DEFAULT NULL COMMENT 原价单位分, quality tinyint(4) DEFAULT NULL COMMENT 成色1-10, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1待审核 2在售 3预订中 4已售出 5下架 6强制下架, stock_version int(11) NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, view_count bigint(20) DEFAULT 0 COMMENT 浏览量, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_category_status (category_id,status), KEY idx_user_id (user_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;注意几个设计细节价格用bigint存“分”不用decimal避免MyBatis里类型转换麻烦也方便Long接收status加上category_id联合索引因为首页分类展示是最常见的查询场景图片不单独建表用goods.image_urls字段存JSON数组减少一次关联查询如果对图片查询很频繁再拆表3.2 扩展表留言、举报、通知、浏览记录核心表之外要支撑完整业务闭环还需要四张扩展表。message表站内私信from_user_id、to_user_id、content、is_read、create_time。站点内聊天时需要根据from_user_id和to_user_id查会话记录这里可以加联合索引(from_user_id, to_user_id, create_time)report表举报target_type举报商品还是评论、target_id、reason、status、handle_user_id、handle_time。后台管理员处理举报后状态要能回溯notice表通知user_id、title、content、type、is_read。比如订单状态变化、审核结果都要推通知给用户browse_record表浏览记录user_id、goods_id、browse_time。用浏览记录做“猜你喜欢”时查询最近N条记录这些扩展表不一定每个页面都用到但设计时先留好回头加功能时就不用再动大表。我的习惯是凡是需要追溯历史的信息都单独建流水表不要在原表上改得面目全非。3.3 索引和事务设计索引不是越多越好事务也不是越宽越好很多初学者拿到表结构后把所有字段都加一遍索引这是不对的。索引会降低写入速度占用磁盘空间。这个项目里真正热点查询是商品列表按分类、状态、时间排序商品标题模糊搜索订单按买家或卖家查列表交易流水按用户查对应的索引就是goods(category_id, status, create_time)、goods(title)全文索引或简单用LIKE、orders(buyer_id, status)、orders(seller_id, status)、trade_record(user_id, create_time)。注意不要给description加索引大字段加索引没意义。事务设计更重要。下单这个操作需要把“更新商品状态”“创建订单”“扣减买家余额”“增加卖家余额”“写入交易流水”放在同一个事务里任何一个失败都要回滚。另外事务不是包得越宽越好。查询操作不要加Transactional否则数据库连接占用时间太长高并发时会把连接池打满。4. 核心源码解析把登录、商品发布、下单这三段代码吃透4.1 JWT登录鉴权的完整链路登录模块我用JWT做无状态鉴权。服务端不保存Session客户端每次请求在Header里带一个Authorization: Bearer token拦截器校验token合法性并从token里取出当前用户ID和角色。这样做的优点是方便前后端分离缺点是需要自己处理token过期和续期。JwtUtil核心代码public class JwtUtil { private static final String SECRET your-secret-key; public static String generateToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 3600_000)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Long getUserId(String token) { Claims claims Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); return Long.valueOf(claims.getSubject()); } }拦截器里要注意两点一是白名单放行比如登录、注册、商品浏览、图片访问不需要token二是用户被禁用后已经发出的token要立即失效。我的处理方式是在Redis里存一个黑名单管理员封禁用户时把该用户的token版本号加1拦截器里比对版本号不匹配就拒绝访问。4.2 商品发布的实现文件上传与参数校验商品发布有两个核心点图片上传和字段校验。图片上传我用MinIO做对象存储不把图片文件存到数据库。MinIO兼容S3协议本地部署很方便和OSS相比没有外网依赖。上传流程是前端用MultipartFile上传图片后端把文件流转成输入流写入MinIO返回图片URL然后把URL数组存入goods.image_urls字段。代码示例PostMapping(/goods) public Result addGoods(RequestBody Valid GoodsDTO dto, RequestHeader(Authorization) String token) { Long userId JwtUtil.getUserId(token); goodsService.addGoods(userId, dto); return Result.ok(); }GoodsDTO里用javax.validation注解做入参校验比如NotBlank(message 标题不能为空)、NotNull(message 价格不能为空)。这里有个小经验不要相信前端传的任何值特别是status。用户提交商品时status只能固定为待审核不能让前端传什么就存什么否则可以绕过审核直接上架。4.3 下单防并发乐观锁把“库存为1”的坑填平下单是这个项目里最有技术含量的方法。前面说过二手商品库存永远是1所以不能用常规的“先查库存再扣减”否则并发请求同时通过检查就会超卖。我的方案是使用自定义SQL加乐观锁Transactional(rollbackFor Exception.class) public Order createOrder(Long goodsId, Long buyerId) { Goods goods goodsMapper.selectById(goodsId); if (goods null || !goods.getStatus().equals(GoodsStatus.ON_SALE)) { throw new BizException(商品不存在或不在售); } int rows goodsMapper.lockStock(goodsId, goods.getStockVersion()); if (rows 0) { throw new BizException(手慢了商品已被下单); } // 生成订单号、创建订单、扣减买家余额、增加卖家余额 // 记录交易流水 return order; }对应的Mapper XMLupdate idlockStock update goods set status 3, stock_version stock_version 1 where id #{goodsId} and status 2 and stock_version #{stockVersion} /update这段SQL的作用是只有当商品仍然是“在售”状态且版本号没有变化时才会更新成功。update影响行数为0说明商品已经被别人下单或状态已变化。我之所以不用select for update悲观锁是因为同一件商品并发下单的冲突概率其实不高乐观锁在绝大多数情况下不会冲突对数据库的压力更小而悲观锁会让所有请求都排队等待商品详情页也可能被锁影响。5. 从源码到可运行SpringBoot版本、MySQL初始化、Docker部署这些坑一次说清5.1 环境选型JDK8还是17SpringBoot 2.7.x还是3.x我见过很多新手用IDEA创建项目时默认生成SpringBoot 3.x然后引入老教程的MyBatis-Plus和各类工具结果就是一堆jar包冲突。SpringBoot 3.x基于Jakarta EE之前写javax.validation、javax.servlet的地方全部要改成jakarta.*MyBatis-Plus必须用3.5.5以上版本很多老博客里的写法直接编译不过。所以个人建议做校园二手交易这个体量的项目直接选择SpringBoot 2.7.18JDK用8或11。它支持JDK17但不用新特性就不影响。等以后真正需要升级再迁现阶段没必要给自己增加“迁移类错误”的排查负担。5.2 MySQL初始化和application.yml的完整配置数据库初始化时要注意如果MySQL是8.0连接URL必须加上时区和SSL参数否则启动会报错。我的application.yml关键配置如下spring: datasource: url: jdbc:mysql://localhost:3306/campus_secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 servlet: multipart: max-file-size: 5MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: your-secret-key expire: 3600000启动前先执行CREATE DATABASE campus_secondhand DEFAULT CHARACTER SET utf8mb4;再导入SQL脚本。这里容易踩的一个坑是数据库字符集没设utf8mb4导致发布商品时中文表情符号存不进去。5.3 Docker部署和常见报错Docker部署SpringBoot项目其实很简单本质是打成一个jar包再丢进容器。我给一个最简DockerfileFROM openjdk:8-jdk-alpine VOLUME /tmp ARG JAR_FILEtarget/*.jar COPY ${JAR_FILE} app.jar EXPOSE 8080 ENTRYPOINT [java,-jar,/app.jar]构建命令mvn clean package -DskipTests docker build -t campus-secondhand:1.0 . docker run -d -p 8080:8080 --name campus campus-secondhand:1.0下面是我排查过程中经常遇到的几个问题报错信息原因解决办法The server time zone value is unrecognizedMySQL连接URL缺少时区参数在url后加serverTimezoneAsia/ShanghaiFailed to configure a DataSource启动时没有找到数据源配置检查application.yml是否在classpath数据库是否已启动java.io.FileNotFoundException: /tmp/...容器内没有上传目录权限Dockerfile里加RUN mkdir -p /data/upload并挂载volumeOutOfMemoryError: insufficient memory容器内存限制启动命令加-Xmx512m6. 这套代码藏在SpringBoot框架里的面试考点防八股问倒6.1 自动配置到底是怎么回事“SpringBoot为什么能自动配置”是必问题。套用这个项目回答最合适项目里引入了spring-boot-starter-data-redisSpringBoot通过EnableAutoConfiguration去读取META-INF/spring.factories或AutoConfiguration.imports里的自动配置类再配合ConditionalOnClass(RedisOperations.class)、ConditionalOnMissingBean这类条件注解自动帮我们创建RedisTemplate、StringRedisTemplate这些Bean。表面上是“自动配置”本质上还是条件和工厂的结合。如果你需要定制可以在自己的配置类里声明一个RedisTemplate的BeanConditionalOnMissingBean检测到已经存在就跳过自动创建。这段逻辑平时不显眼但理解了之后排查“为什么我配置没生效”会快很多。6.2 项目中哪些地方用到了AOP和事务事务用的是Transactional。面试官特别喜欢问“事务失效场景”我在项目里实际踩过createOrder方法调用本类另一个事务方法结果内部方法的Transactional没生效。原因很简单Spring的事务是通过AOP代理实现的同类调用走的是this而不是代理对象所以代理切面根本没执行。解决办法要么把内部方法拆到另一个Service要么用AopContext.currentProxy()。AOP除了事务我还用它做管理员操作审计日志。比如审核商品、处理举报这类后台操作定义一个自定义注解AdminLog再写一个Aspect切面在方法执行前后记录操作人、操作类型、操作参数、耗时。这样比在每个Controller里手写日志要清爽得多也展示了你对AOP的理解。6.3 表设计通用方法论和WMS数据库设计是同一个套路有人问“WMS系统怎么设计数据库表”时我意识到其实和二手交易平台设计是同一套方法论。可以把“系统里所有重要业务对象”拆成四层主表记录核心对象及其当前状态例如订单表、入库单表子表/明细表记录核心对象包含的具体条目例如订单明细、入库单明细流水表记录所有历史变更例如交易流水、库存变动流水唯一业务单号每张主表都生成一个全局唯一的业务编号order_no、入库单号并建立唯一索引用于幂等和问题追溯这套方法论不是只能用在校园二手平台WMS里的库存管理、ERP里的订单处理本质上都是这样一层一层拆出来的。聊到这个不仅能体现你会写SQL还能体现你对系统设计的思考深度。7. 持续迭代方向不要把项目停在“演示可用”7.1 什么情况下不需要拆微服务很多人做完单体项目就想往上堆Nacos、Gateway、Feign觉得微服务显得“高级”。我也曾经这么做过但最后发现没有千万级用户、没有多团队并行开发微服务带来的服务治理成本远大于收益。校园二手交易平台用单体架构完全合理真正需要演进的方向不是拆服务而是把单体的代码质量和可观测性做好比如加接口限流、日志采集、慢SQL监控。7.2 想真正落地还需要补什么要让这套系统在学校真正投入使用至少要补齐这几块真实支付微信/支付宝需要商户资质校园场景可以用模拟支付演示但代码里要预留支付回调接口消息推送下单后需要通知卖家可以用RabbitMQ做异步通知避免下单响应时间被邮件或短信拖慢内容审核发布商品时图片和文字需要先经过云服务审核防止违规内容数据脱敏管理员查看用户列表时手机号、学号不能明文展示接口防刷用Redis实现滑动窗口限流避免商品详情和登录接口被恶意刷最后分享一个很实际的调试技巧。下单并发是一个容易翻车也特别容易出彩的测试点在本地启动项目后用JMeter建20个线程同时抢同一件商品观察请求返回和数据库里该商品的stock_version、status变化。我第一次跑的时候出现了两条订单同时成功的现象后来正是在这条复现路径上定位到问题——更新SQL漏了status2条件导致已经预订的商品还能被update。很多表面上“有源码就完事”的项目恰恰在这种并发细节里见高下。本文还有配套的精品资源点击获取 SpringBoot校园二手交易平台实战：从数据库设计到并发下单部署全解析
简介在Java后端开发中SpringBoot凭借自动配置机制大幅降低了环境搭建成本已成为构建企业级应用的主流框架。而校园二手交易平台作为典型的业务闭环项目天然覆盖用户认证、商品状态机、订单并发控制等核心场景非常适合用来理解框架原理与工程实践的配合。围绕这一主题文章从业务模块拆分出发梳理了用户、商品、交易三大核心域的表结构设计方法强调了价格用分存储、状态流转、事务边界等细节同时深入解析了基于乐观锁的防超卖下单逻辑以及JWT鉴权、文件上传、Docker部署等落地技术。对于正在准备毕业设计或希望提升SpringBoot实战能力的开发者这套完整方案既提供了可复用的数据库设计方法论也给出了从源码到可运行系统的避坑指南。 做毕设选题的时候十个Java方向的人里有九个会刷到“校园二手交易平台”这句话毫不夸张。但真正把源码下载下来能顺利跑起来、还能跟面试官讲清楚技术点的人十个里未必有一个。我做过一套基于SpringBoot的校园二手交易平台源码和数据库设计都完整整理过这中间踩了不少坑——SpringBoot版本兼容、MySQL表结构反复推倒重来、并发下单一不小心就超卖。这篇文章就把这套项目的经验从头梳理一遍不堆砌源码文件而是把模块划分、数据库设计、核心代码、部署坑点以及面试怎么答都讲透。无论你是刚学完Java基础想找项目练手还是准备用SpringBoot做毕业设计或者想从“会抄代码”进步到“能讲设计”这篇都值得认真看完。1. 为什么这个项目比“合租系统”“博客系统”更适合做Java练手项目1.1 校园二手交易的业务闭环决定了它的技术含量很多人选毕设题目时会考虑图书管理系统、博客系统、在线商城。这些系统确实简单但做完之后你会发现它们大多只是“多个表的CRUD”没有多少业务逻辑可讲。校园二手交易平台不一样它有自己的完整业务闭环学生注册后进行校园身份认证认证通过后可以发布闲置买家通过搜索、分类、收藏找到商品买卖双方经过站内聊天沟通细节买家下单后走站内余额模拟支付卖家发货、买家确认收货交易完成后双方可以互相评价如果出现问题还有举报和申诉流程管理员在后端进行商品审核、用户封禁、数据统计。这套流程决定了项目不是一堆孤立的表而是各个模块相互咬合的状态流转。比如商品不是删掉就消失而是有草稿、待审核、在售、预订、已售、强制下架的状态路径订单不是简单的insert而是先检查商品是否在售再乐观锁更新商品状态最后创建订单、扣减余额。这些逻辑写下来才是真正的“业务开发”。1.2 为什么要选SpringBootMyBatis-Plus这套组合选型的理由很多人答不上来。我的看法是SpringBoot的价值不是“快”而是它通过自动配置把环境差异收敛掉了。你在A机器上能跑换到B机器也能跑这对训练项目和实际交付太重要了。MyBatis-Plus把单表CRUD封装好了写起来比原生MyBatis少很多代码但它不是万能药像订单状态变更、库存扣减这种强一致性的写操作我都是写自定义SQL加乐观锁完全依赖BaseMapper是不合适的。我在这套项目里的推荐组合是SpringBoot 2.7.18 JDK 8 MySQL 8.0 MyBatis-Plus 3.5.3 Redis MinIO JWT。这套组合偏保守但稳定。后面章节我会专门说为什么不要一上来就追SpringBoot 3.x。2. 模块拆解先画清楚“人、货、单”三个核心域2.1 用户域不是简单地建一张user表用户模块最容易被做成一张只包含账号密码的user表我见过很多半成品就是这么干的。但校园二手平台有个特殊点用户需要证明自己是该校学生。于是在user表外我还设计了一张student_certification表用来存学号、姓名、所在院系、学生卡图片URL、认证状态。user表本身只放通用登录字段认证信息单独放原因是认证是一次性的低频操作拆开既能减少user表宽度也方便后台审核时只查认证表。user表核心字段id、username、password、nickname、avatar、phone、role0普通用户1管理员、status0禁用1正常、points信誉积分、create_time、update_time。密码存的是BCrypt加密后的字符串不是明文。这里有一个容易被忽略的点用户状态和登录逻辑要联动。如果账号被管理员禁用登录时不能只查用户名和密码还要校验status字段否则被处罚的用户依然可以正常登录。2.2 商品域发布到下架的完整状态机商品域的灵魂是状态。如果你的goods表里只有一个status字段但代码里没有一套状态流转逻辑那和普通文章表没有区别。我的状态设计为0草稿、1待审核、2在售、3预订中、4已售出、5下架、6管理员强制下架。为什么要有待审核因为不是所有学生都会规范发布商品后台管理员需要审核图片和标题防止出现违规品类。为什么要区分“预订中”和“已售出”因为线下交易存在“我先预订然后当面交付”的环节没有这个状态用户并发下单就控制不住。商品表字段包括id、user_id发布者、category_id、title、description、price单位分、original_price、quality成色、image_urlsJSON数组存图集、status、stock_version乐观锁版本号、view_count、create_time、update_time。价格我建议统一用“分”来表示不要用double否则订单金额计算会出现浮点误差这是个老生常谈但很容易踩的坑。2.3 交易域二手交易不是标准电商订单是所有模块里最容易出错的。二手交易和标准电商最大的差异是库存永远是1不允许超卖。标准电商可以扣减库存二手场景则应该是“下单即锁定商品”成功创建订单后商品状态从在售变为预订中其他人不能再下单。所以order表不能单纯当作订单记录表它实际承担了商品状态的“触发器”。订单表字段id、order_no、goods_id、buyer_id、seller_id、amount单位分、status0待支付1待发货2待收货3已完成4退款中5已关闭、pay_type0站内余额1线下交付、pay_time、deliver_time、receive_time、close_time、remark、create_time。另外还要一张trade_record表用来记录每次余额扣减和收入增加类似流水账对账和排查问题都用得上。3. 数据库设计9张核心表4张扩展表表和表之间的业务逻辑要能讲明白3.1 核心表的结构设计与建表SQL数据库设计不能一上来就建表而是先把业务对象拆成“主表子表状态流水”四个层次。以订单为例orders是主表记录一次交易的核心内容订单操作记录是流水表记录状态变更历史如果涉及退款还要有refund_record表。下表是我归纳出的核心表清单表名职责关键字段user账号登录与基本信息username、password、role、statusstudent_certification学生认证资料user_id、student_no、campus_card_url、auth_statusgoods_category商品分类name、parent_id、sortgoods商品信息user_id、category_id、status、stock_versiongoods_image商品图片goods_id、url、sortorders订单主表order_no、goods_id、buyer_id、seller_id、statustrade_record余额流水user_id、type、amount、balance_before、balance_afterfavorite收藏user_id、goods_id、create_timemessage站内私信from_user_id、to_user_id、content、is_read这里给出goods表的建表SQL注意索引和注释CREATE TABLE goods ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 发布者ID, category_id bigint(20) DEFAULT NULL COMMENT 分类ID, title varchar(120) NOT NULL COMMENT 标题, description text COMMENT 描述, price bigint(20) NOT NULL COMMENT 价格单位分, original_price bigint(20) DEFAULT NULL COMMENT 原价单位分, quality tinyint(4) DEFAULT NULL COMMENT 成色1-10, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1待审核 2在售 3预订中 4已售出 5下架 6强制下架, stock_version int(11) NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, view_count bigint(20) DEFAULT 0 COMMENT 浏览量, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_category_status (category_id,status), KEY idx_user_id (user_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;注意几个设计细节价格用bigint存“分”不用decimal避免MyBatis里类型转换麻烦也方便Long接收status加上category_id联合索引因为首页分类展示是最常见的查询场景图片不单独建表用goods.image_urls字段存JSON数组减少一次关联查询如果对图片查询很频繁再拆表3.2 扩展表留言、举报、通知、浏览记录核心表之外要支撑完整业务闭环还需要四张扩展表。message表站内私信from_user_id、to_user_id、content、is_read、create_time。站点内聊天时需要根据from_user_id和to_user_id查会话记录这里可以加联合索引(from_user_id, to_user_id, create_time)report表举报target_type举报商品还是评论、target_id、reason、status、handle_user_id、handle_time。后台管理员处理举报后状态要能回溯notice表通知user_id、title、content、type、is_read。比如订单状态变化、审核结果都要推通知给用户browse_record表浏览记录user_id、goods_id、browse_time。用浏览记录做“猜你喜欢”时查询最近N条记录这些扩展表不一定每个页面都用到但设计时先留好回头加功能时就不用再动大表。我的习惯是凡是需要追溯历史的信息都单独建流水表不要在原表上改得面目全非。3.3 索引和事务设计索引不是越多越好事务也不是越宽越好很多初学者拿到表结构后把所有字段都加一遍索引这是不对的。索引会降低写入速度占用磁盘空间。这个项目里真正热点查询是商品列表按分类、状态、时间排序商品标题模糊搜索订单按买家或卖家查列表交易流水按用户查对应的索引就是goods(category_id, status, create_time)、goods(title)全文索引或简单用LIKE、orders(buyer_id, status)、orders(seller_id, status)、trade_record(user_id, create_time)。注意不要给description加索引大字段加索引没意义。事务设计更重要。下单这个操作需要把“更新商品状态”“创建订单”“扣减买家余额”“增加卖家余额”“写入交易流水”放在同一个事务里任何一个失败都要回滚。另外事务不是包得越宽越好。查询操作不要加Transactional否则数据库连接占用时间太长高并发时会把连接池打满。4. 核心源码解析把登录、商品发布、下单这三段代码吃透4.1 JWT登录鉴权的完整链路登录模块我用JWT做无状态鉴权。服务端不保存Session客户端每次请求在Header里带一个Authorization: Bearer token拦截器校验token合法性并从token里取出当前用户ID和角色。这样做的优点是方便前后端分离缺点是需要自己处理token过期和续期。JwtUtil核心代码public class JwtUtil { private static final String SECRET your-secret-key; public static String generateToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 3600_000)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Long getUserId(String token) { Claims claims Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); return Long.valueOf(claims.getSubject()); } }拦截器里要注意两点一是白名单放行比如登录、注册、商品浏览、图片访问不需要token二是用户被禁用后已经发出的token要立即失效。我的处理方式是在Redis里存一个黑名单管理员封禁用户时把该用户的token版本号加1拦截器里比对版本号不匹配就拒绝访问。4.2 商品发布的实现文件上传与参数校验商品发布有两个核心点图片上传和字段校验。图片上传我用MinIO做对象存储不把图片文件存到数据库。MinIO兼容S3协议本地部署很方便和OSS相比没有外网依赖。上传流程是前端用MultipartFile上传图片后端把文件流转成输入流写入MinIO返回图片URL然后把URL数组存入goods.image_urls字段。代码示例PostMapping(/goods) public Result addGoods(RequestBody Valid GoodsDTO dto, RequestHeader(Authorization) String token) { Long userId JwtUtil.getUserId(token); goodsService.addGoods(userId, dto); return Result.ok(); }GoodsDTO里用javax.validation注解做入参校验比如NotBlank(message 标题不能为空)、NotNull(message 价格不能为空)。这里有个小经验不要相信前端传的任何值特别是status。用户提交商品时status只能固定为待审核不能让前端传什么就存什么否则可以绕过审核直接上架。4.3 下单防并发乐观锁把“库存为1”的坑填平下单是这个项目里最有技术含量的方法。前面说过二手商品库存永远是1所以不能用常规的“先查库存再扣减”否则并发请求同时通过检查就会超卖。我的方案是使用自定义SQL加乐观锁Transactional(rollbackFor Exception.class) public Order createOrder(Long goodsId, Long buyerId) { Goods goods goodsMapper.selectById(goodsId); if (goods null || !goods.getStatus().equals(GoodsStatus.ON_SALE)) { throw new BizException(商品不存在或不在售); } int rows goodsMapper.lockStock(goodsId, goods.getStockVersion()); if (rows 0) { throw new BizException(手慢了商品已被下单); } // 生成订单号、创建订单、扣减买家余额、增加卖家余额 // 记录交易流水 return order; }对应的Mapper XMLupdate idlockStock update goods set status 3, stock_version stock_version 1 where id #{goodsId} and status 2 and stock_version #{stockVersion} /update这段SQL的作用是只有当商品仍然是“在售”状态且版本号没有变化时才会更新成功。update影响行数为0说明商品已经被别人下单或状态已变化。我之所以不用select for update悲观锁是因为同一件商品并发下单的冲突概率其实不高乐观锁在绝大多数情况下不会冲突对数据库的压力更小而悲观锁会让所有请求都排队等待商品详情页也可能被锁影响。5. 从源码到可运行SpringBoot版本、MySQL初始化、Docker部署这些坑一次说清5.1 环境选型JDK8还是17SpringBoot 2.7.x还是3.x我见过很多新手用IDEA创建项目时默认生成SpringBoot 3.x然后引入老教程的MyBatis-Plus和各类工具结果就是一堆jar包冲突。SpringBoot 3.x基于Jakarta EE之前写javax.validation、javax.servlet的地方全部要改成jakarta.*MyBatis-Plus必须用3.5.5以上版本很多老博客里的写法直接编译不过。所以个人建议做校园二手交易这个体量的项目直接选择SpringBoot 2.7.18JDK用8或11。它支持JDK17但不用新特性就不影响。等以后真正需要升级再迁现阶段没必要给自己增加“迁移类错误”的排查负担。5.2 MySQL初始化和application.yml的完整配置数据库初始化时要注意如果MySQL是8.0连接URL必须加上时区和SSL参数否则启动会报错。我的application.yml关键配置如下spring: datasource: url: jdbc:mysql://localhost:3306/campus_secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 servlet: multipart: max-file-size: 5MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: your-secret-key expire: 3600000启动前先执行CREATE DATABASE campus_secondhand DEFAULT CHARACTER SET utf8mb4;再导入SQL脚本。这里容易踩的一个坑是数据库字符集没设utf8mb4导致发布商品时中文表情符号存不进去。5.3 Docker部署和常见报错Docker部署SpringBoot项目其实很简单本质是打成一个jar包再丢进容器。我给一个最简DockerfileFROM openjdk:8-jdk-alpine VOLUME /tmp ARG JAR_FILEtarget/*.jar COPY ${JAR_FILE} app.jar EXPOSE 8080 ENTRYPOINT [java,-jar,/app.jar]构建命令mvn clean package -DskipTests docker build -t campus-secondhand:1.0 . docker run -d -p 8080:8080 --name campus campus-secondhand:1.0下面是我排查过程中经常遇到的几个问题报错信息原因解决办法The server time zone value is unrecognizedMySQL连接URL缺少时区参数在url后加serverTimezoneAsia/ShanghaiFailed to configure a DataSource启动时没有找到数据源配置检查application.yml是否在classpath数据库是否已启动java.io.FileNotFoundException: /tmp/...容器内没有上传目录权限Dockerfile里加RUN mkdir -p /data/upload并挂载volumeOutOfMemoryError: insufficient memory容器内存限制启动命令加-Xmx512m6. 这套代码藏在SpringBoot框架里的面试考点防八股问倒6.1 自动配置到底是怎么回事“SpringBoot为什么能自动配置”是必问题。套用这个项目回答最合适项目里引入了spring-boot-starter-data-redisSpringBoot通过EnableAutoConfiguration去读取META-INF/spring.factories或AutoConfiguration.imports里的自动配置类再配合ConditionalOnClass(RedisOperations.class)、ConditionalOnMissingBean这类条件注解自动帮我们创建RedisTemplate、StringRedisTemplate这些Bean。表面上是“自动配置”本质上还是条件和工厂的结合。如果你需要定制可以在自己的配置类里声明一个RedisTemplate的BeanConditionalOnMissingBean检测到已经存在就跳过自动创建。这段逻辑平时不显眼但理解了之后排查“为什么我配置没生效”会快很多。6.2 项目中哪些地方用到了AOP和事务事务用的是Transactional。面试官特别喜欢问“事务失效场景”我在项目里实际踩过createOrder方法调用本类另一个事务方法结果内部方法的Transactional没生效。原因很简单Spring的事务是通过AOP代理实现的同类调用走的是this而不是代理对象所以代理切面根本没执行。解决办法要么把内部方法拆到另一个Service要么用AopContext.currentProxy()。AOP除了事务我还用它做管理员操作审计日志。比如审核商品、处理举报这类后台操作定义一个自定义注解AdminLog再写一个Aspect切面在方法执行前后记录操作人、操作类型、操作参数、耗时。这样比在每个Controller里手写日志要清爽得多也展示了你对AOP的理解。6.3 表设计通用方法论和WMS数据库设计是同一个套路有人问“WMS系统怎么设计数据库表”时我意识到其实和二手交易平台设计是同一套方法论。可以把“系统里所有重要业务对象”拆成四层主表记录核心对象及其当前状态例如订单表、入库单表子表/明细表记录核心对象包含的具体条目例如订单明细、入库单明细流水表记录所有历史变更例如交易流水、库存变动流水唯一业务单号每张主表都生成一个全局唯一的业务编号order_no、入库单号并建立唯一索引用于幂等和问题追溯这套方法论不是只能用在校园二手平台WMS里的库存管理、ERP里的订单处理本质上都是这样一层一层拆出来的。聊到这个不仅能体现你会写SQL还能体现你对系统设计的思考深度。7. 持续迭代方向不要把项目停在“演示可用”7.1 什么情况下不需要拆微服务很多人做完单体项目就想往上堆Nacos、Gateway、Feign觉得微服务显得“高级”。我也曾经这么做过但最后发现没有千万级用户、没有多团队并行开发微服务带来的服务治理成本远大于收益。校园二手交易平台用单体架构完全合理真正需要演进的方向不是拆服务而是把单体的代码质量和可观测性做好比如加接口限流、日志采集、慢SQL监控。7.2 想真正落地还需要补什么要让这套系统在学校真正投入使用至少要补齐这几块真实支付微信/支付宝需要商户资质校园场景可以用模拟支付演示但代码里要预留支付回调接口消息推送下单后需要通知卖家可以用RabbitMQ做异步通知避免下单响应时间被邮件或短信拖慢内容审核发布商品时图片和文字需要先经过云服务审核防止违规内容数据脱敏管理员查看用户列表时手机号、学号不能明文展示接口防刷用Redis实现滑动窗口限流避免商品详情和登录接口被恶意刷最后分享一个很实际的调试技巧。下单并发是一个容易翻车也特别容易出彩的测试点在本地启动项目后用JMeter建20个线程同时抢同一件商品观察请求返回和数据库里该商品的stock_version、status变化。我第一次跑的时候出现了两条订单同时成功的现象后来正是在这条复现路径上定位到问题——更新SQL漏了status2条件导致已经预订的商品还能被update。很多表面上“有源码就完事”的项目恰恰在这种并发细节里见高下。本文还有配套的精品资源点击获取