校园二手交易平台毕设源码拆解：从业务逻辑到部署安全

每年毕业设计季，我收到最多的私信类型就是：博主，这个源码我下载下来了，但跑不起来，怎么办？他们口中的源码，经常就是类似“06279校园二手商品交易平台”这种带编号的资源包。作为长期帮人看项目源码的人，我可以负责任地说一句：源码不是用来珍藏的，是用来读、用来说清楚的。这篇博文，我拿校园二手商品交易平台来做一个完整的案例分析——从业务逻辑到技术选型，从数据库设计到核心流程，再到位了手之后的部署和安全改造，全部过一遍。适合正在做课设/毕设的计算机方向同学，也适合想快速理解一个小型交易系统是怎么运作的读者。

1. 先别急着看代码：校园二手交易平台的业务逻辑和边界

1.1 它和淘宝/闲鱼最大的区别是什么

校园二手交易平台，本质上是“二手电商”在校园这个封闭环境里的变体。它跟淘宝、闲鱼这些通用平台最大的区别不在技术，而在业务约束。用户群体高度集中，都是在校学生和老师，大家活动范围小、彼此之间多少有点共同身份，所以信任成本比陌生人交易低得多。商品类型也非常聚焦，教材教辅、考研资料、宿舍电器、自行车、健身器材是主力，而不是五花八门的全品类商品。交易方式上，绝大多数情况是线下当面交易，扫码付钱或者现金都可以，在线支付并不是必选项。

这些业务特征直接决定系统的复杂程度。很多通用电商平台必须做的支付网关、物流跟踪、售后纠纷仲裁，到这个项目里基本可以砍掉。系统要做好的，是“商品信息撮合”这一件事。把这句话想明白，再看源码，思路会清晰很多。很多同学一上来就想把页面做得跟闲鱼一样花哨，却没有思考过用户到底在这个平台上完成什么任务，最后做出来的东西华而不实，答辩时也很难讲清楚。

1.2 一个最小可用的功能闭环

如果只做一个最小可用版本，功能闭环可以拆成四条线。

用户侧：注册、登录、个人资料维护、查看“我发布的”“我买到的”“我卖出的”。这里注意，“我买到的”和“我卖出的”是买家、卖家两种视角，同一个用户在不同订单里会扮演不同角色，这是订单表设计的核心难点，后面会展开说。

商品侧：发布商品、编辑信息、手动上下架、按分类浏览、关键词搜索、商品收藏。发布商品时要传标题、描述、价格、成色、分类和图片，这是整个平台信息质量的关键入口。信息质量直接决定平台有没有用，一个满屏“标题乱填、图片模糊”的二手平台，用户用一次就不会再来了。

交易侧：买家对商品发起“我想要”，生成订单；卖家确认订单，双方进入线下交易环节；交易完成，订单标记完成。整个过程不涉及线上支付，所以订单状态机相对简单，但依然要处理“取消”“超时”这些例外。比如买家下单后卖家一直不确认怎么办，要不要加个超时自动取消，这些都属于业务边界问题。

管理侧：管理员登录后台，对用户和商品进行审核管理，发布平台公告。这个模块很多同学容易忽略，但答辩时老师非常喜欢问“平台怎么治理垃圾信息和虚假交易”，管理侧就是用来回答这个问题的。哪怕只是简单支持商品强制下架和用户禁用，也比完全不做强得多。

四条线合起来，就是“用户—商品—订单”这个核心三角。任何二手平台，不管外表多花哨，底层都是这个结构。

1.3 案例分析的正确打开方式

拿到一个源码包，第一件事不是立刻启动IDEA挨个点开Controller，而是先看项目的README、数据库脚本、配置文件。我见过太多同学打开项目就找登录功能，结果改了半小时还是报错，后来发现密码字段根本没加密、数据库都还没导入。正确的顺序是：先看表结构，再看接口文档，然后跑通项目，最后才谈改代码。如果只允许看一个文件，我会选初始化SQL脚本。表结构能直接反映作者对业务的理解程度，字段设计得规整，后面的代码大概率也不会太乱。

还有一个很实用的习惯：先把项目跑起来，用管理员账号登录后台看一眼，再注册一个普通用户走一遍发布商品的流程。这样你就知道“正常路径”是什么样，出了问题也有参照物。别小看这一步，它能帮你把项目的全貌和代码里的人名、表名串起来，后面读代码时会有种“一切都在掌握中”的感觉。

2. 技术选型拆解：为什么这类项目普遍长这个样子

2.1 最常见的三种技术栈

把校园二手交易平台这类毕业设计项目翻一遍，技术栈基本跑不出下面三套。

具体是哪一套，取决于资源包作者的技术背景。但不管哪套，里面都有几个绕不开的公共点：MySQL存数据，HTTP接口做前后端交互，页面负责展示和收集数据。把这三件事记住，项目骨架就出来了。如果看到项目里用的是JSP而不是Vue，也不用慌，目录结构无非是从“controller→service→dao”变成了“servlet→service→dao”，核心思维是一样的。

2.2 单体架构足够用，别给自己挖坑

看到有些同学在二手交易项目里想上微服务、Redis缓存、消息队列，我都是劝退的。不是这些技术不好，是场景不匹配。校园二手交易平台一天能有多少并发？一个校区几千人同时在线已经算多了，单体应用配一台普通机器完全扛得住。微服务要拆服务、管注册中心、处理分布式事务，光把这些环境跑起来就够喝一壶的，更别说答辩时老师追问“为什么这么拆”。

技术的选择应该由需求驱动，而不是反过来。真要说优化空间，把MySQL的慢查询优化好、加个索引、做好分页，性价比比引入一套分布式框架高得多。有些同学觉得项目里不写点Redis就不时髦，但如果数据量连缓存都触发不了，Redis加进去反而成了负担。你可以在答辩时说“我考虑过，但当前业务量不需要引入”，这句话比硬塞一个组件真诚得多，也更能体现你的思考能力。

2.3 源码包的标准目录结构

大部分基于 Spring Boot 的项目，目录长这样：

code复制src/main/java/com/campus/secondhand
├── controller   # 接收HTTP请求
├── service      # 业务逻辑
├── mapper       # 数据访问层
├── entity       # 数据库实体类
└── config       # 配置类
src/main/resources
├── mapper       # MyBatis XML文件
└── application.yml

拿到源码后，定位一个功能最快的方法是反向追：页面请求的URL → Controller的@RequestMapping → Service的实现类 → Mapper的SQL。比如想查“发布商品”这个东西是怎么写的，就去Controller里找包含goods和post关键词的方法。这个路径走顺了，读代码的速度能快一倍。很多同学读代码喜欢从头一页一页读，那是错误姿势。代码不是书，是地图，你要找的是坐标，不是从头背到尾。

3. 数据库设计：整张表结构才是二手平台的真正地基

3.1 核心表有哪些

任何交易系统，核心表都逃不过用户、商品、订单这三张，外加分类、收藏等辅助表。校园二手平台通常至少会有这几张表。

这几张表的关系，一句话就能说明白：一个用户能发布多个商品，一个商品属于一个用户；一个用户能收藏多个商品，一个商品能被多个用户收藏；一个商品对应一个订单，但订单同时要记录买家是谁、卖家是谁。

这里重点说订单表。很多新手第一次设计订单表时会写错，只放一个user_id，结果分不清谁是谁。订单表里buyer_id和seller_id两个字段，一个是买家的用户ID，一个是卖家的用户ID，这个设计直接决定了后续“我买到的”和“我卖出的”两个列表好不好查。如果你看到某套源码的订单表只有user_id，那基本可以判断作者对业务的理解不够深，这套代码的参考价值要大打折扣。

3.2 status 字段：用状态机代替物理删除

看项目源码的时候，重点看两个status：商品表的status和订单表的status。商品状态通常有“审核中/在售/已售/下架/草稿”这几种，订单状态一般是“待卖家确认/待交易/已完成/已取消”。状态用整数值存，页面上做映射展示。

为什么要设计成状态而不是直接删掉？因为交易平台需要留痕。商品被人下单了，你不能把记录直接物理删除，否则统计和追溯都无从谈起；用户主动下架商品，也不是“删”，而是status改成下架。这种状态机设计的好处是，所有历史数据都在，出问题时可以回溯。数据库层面做的是update操作而不是delete操作，这是交易系统的基本素养。

以商品状态为例，常见的一种设计是这样的：

订单状态则更关心流程推进：买家提交订单之后，卖家确认前，订单处于“待确认”；卖家确认后进入“待交易”；线下完成时“已完成”；任何一方取消则为“已取消”。整个流程都靠status字段驱动，而不是删数据。

3.3 改表前的三个提醒

如果你打算在这套源码上做二次开发，动表结构前先看三处。第一，价格字段是不是decimal，如果不是，改成decimal(10,2)，不要用float或double，浮点型算金额会有精度问题。你不想看到1.0元加2.0元等于3.0000000000000004这种结果。第二，图片字段存的是什么，相对路径或URL都行，但别把图片base64直接塞进数据库，那样表会变得很大，查询也会很慢。第三，时间字段要么用datetime要么用timestamp，而且要注意时区问题，统一写入Asia/Shanghai，否则跑起来可能遇到“时间差8小时”的怪问题。

4. 从源码里抠出三条核心链路是什么体验

4.1 发布商品的完整链路

一条商品从用户在页面上填写到最终展示在首页，链路是这样的：前端表单收集标题、描述、价格、成色、分类，同时把图片传给上传接口；后端Controller接收数据，经过简单的参数校验后交给Service；Service把当前登录用户ID填进userId字段，初始状态设置为在售；然后调用Mapper插入这条记录；首页查询接口按创建时间倒序，就能把新商品刷出来。

用Spring Boot风格的代码演示，大体长这样：

java复制@PostMapping("/goods")
public Result addGoods(@RequestBody GoodsDTO dto) {
    // 参数校验：标题、价格、分类不能为空
    Goods goods = new Goods();
    BeanUtils.copyProperties(dto, goods);
    goods.setUserId(CurrentUser.getId());
    goods.setStatus(GoodsStatus.ON_SALE.getCode());
    goods.setViewCount(0);
    goods.setCreateTime(LocalDateTime.now());
    goodsService.save(goods);
    return Result.success(goods.getId());
}

注意看它给userId赋值用的是当前登录用户，而不是前端传来的任何值。这种“从会话里取用户身份”的写法，能挡住大多数越权操作。如果源码里让你手动传userId，那这个项目在权限上是有问题的，改造要优先做。

图片上传是这个环节里最容易被卡住的地方。很多源码把上传逻辑写成了一个单独接口，前端先调上传接口拿到图片URL，再随表单一起提交。这种做法是对的，但要注意上传接口有没有限制文件类型和大小。如果没限制，那就属于一个明显的安全隐患，下面专门有一章讲。

4.2 搜索和分类筛选怎么实现

搜索是二手平台的高频入口，很多同学会忽略这块，但答辩时老师很喜欢问。最常见的实现就是SQL里的like模糊查询，加上分类条件过滤，然后分页。MyBatis XML里的典型写法是这样的：

xml复制<select id="searchGoods" resultType="Goods">
    SELECT * FROM goods
    <where>
        <if test="keyword != null and keyword != ''">
            AND (title LIKE CONCAT('%', #{keyword}, '%')
                 OR description LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="categoryId != null">
            AND category_id = #{categoryId}
        </if>
        AND status = 1
    </where>
    ORDER BY create_time DESC
    LIMIT #{offset}, #{pageSize}
</select>

注意几个细节：关键词同时匹配标题和描述，覆盖面更大；状态条件固定为在售，下架和已售商品不参与搜索；用LIMIT做分页而不是一次查全表。这种方式对数据量不大的系统完全够用，没必要上来就引入Elasticsearch。

分页参数怎么传也很讲究。前端传pageNum和pageSize，后端换算成offset。有的源码接口直接让前端传offset和limit，没有不对，只是语义上不如pageNum清晰。如果发现分页查出来数据重复或者漏数据，先检查排序字段是否稳定，加上id作为第二排序条件可以解决大部分问题。

4.3 订单状态流转：买卖双方的角色怎么切换

订单的核心难点，是同一个用户在不同订单里可能扮演不同角色。一个学生今天发布了旧书，明天去别人的帖子里买台灯，那么他在订单A里是卖家，在订单B里是买家。所以订单表里buyer_id和seller_id两个字段缺一不可，查询