开始前的三件事：先把“拿到代码”变成“看懂代码”
如果你手里正好是这套 Spring Boot 校园二手交易平台（lca16），我猜你现在最想干的不是看功能介绍，而是赶紧让它跑起来。这个心情我很理解，因为我前后帮几十位同学调过类似的项目。学期末那段时间，几乎每天都有同样的问题冒出来：“代码下载好了但启动报错”“数据库导入失败”“页面出来了但图片不显示”。一路排查下来，90%的锅都不在业务代码，而在开发环境、依赖版本、数据库初始化这几步。
这篇文章不打算把它当商品介绍写，而是站在“我接手了一套完整源码后，该怎么落地”的角度，把环境搭建、数据库设计、核心功能拆解、调试部署、答辩改造这整条链路讲透。文章里所有配置和步骤，都按这套项目最常见的组合来给——Spring Boot 2.x + MySQL + MyBatis Plus，这也是我实测下来课设项目里踩坑最少的组合。适合正在做课程设计、毕设选型，或者想找一个完整项目吃透 Java 全栈开发流程的同学。如果你希望的是“拿到就能演示、看懂还能回答提问”，那这篇文章就是照着这个目标写的。
这中间我会把我实际踩过的坑、帮别人排过的错、答辩时老师爱问的问题都揉进去，尽量让这篇东西不仅能帮你跑通项目，还能让你在跑通之后，对每个模块为什么这么设计心里有数。
1. 为什么校园二手交易是 Spring Boot 课设项目的“常青树”
1.1 需求真实，场景自带说服力
先说一个很多同学忽略的点：做课设选题目，最怕的不是功能多，而是功能“假”。有些题目一眼就暴露是虚构需求——比如一套“小区物业管理系统”，除了管理员自己录入，根本看不出有什么真实使用场景，答辩时老师问一句“这个系统解决什么问题”，很容易卡住。而校园二手交易这个方向，需求是天然存在的，每个学校都有毕业季学长学姐甩卖教材、考研资料、电风扇、显示器的时候，也有新生开学想淘便宜代步工具的刚需。
这类项目天生就有三个角色：买家、卖家、管理员。买家要浏览、搜索、下单、付款（或者站内留言沟通）；卖家要发布商品、上下架、管理订单；管理员要审核商品、管理用户、处理举报或违规信息。三条线一交叉，业务流程立刻立起来了，不是那种一个人就能自娱自乐的假系统。所以你写论文、做答辩PPT的时候，第一页就可以直接写：本系统针对高校内二手物品流转效率低、信息分散在学生群和贴吧的痛点，提供一个集中的线上交易平台。这句话一出来，评委就知道你做过需求分析。
1.2 技术覆盖面恰到好处，难度不会失控
我自己看过不少课设题目，有的过于简单，比如“学生信息管理系统”，本质上就是一张表的增删改查，做完之后你自己都不好意思写在简历上。有的又过于复杂，比如“基于微服务的电商平台”，一个课设拆成十几个服务，最后连本地联调都跑不通，更别提写论文了。
校园二手交易平台刚好处在一个非常舒服的中间档位：它不是一个纯 CRUD 系统，因为订单有状态流转、商品有上下架规则、用户有角色权限，这些是真正的业务逻辑；但它又没有复杂的支付对账、库存扣减、分布式事务，难度完全撑得住一个学生的独立开发。
Spring Boot 里最常见的几块能力，这个项目全都能碰到：
- 分层架构：Controller、Service、Mapper 三层，理解 Java 后端的基础组织方式；
- 数据库设计：至少五六张核心表，外键关系、索引、状态字段都要考虑；
- 文件上传下载：商品图片的存储与访问，这是真实系统逃不开的环节；
- 分页与模糊搜索：商品列表、关键词筛选，是 MyBatis Plus 最典型的使用场景；
- 权限控制：登录状态校验、管理员拦截器，涉及 Filter/Interceptor 的实战用法；
- 打包部署：最终产物是一个可运行的 JAR 包，能演示从本地到服务器的完整部署流程。
这些能力不只是课设要用，你以后面试实习，简历上写着“熟悉 Spring Boot”，面试官默认你会的东西基本也就是这一层。所以这个项目的价值不是“交差”，而是用最小成本把 Java 后端的主干流程走一遍。
1.3 比“商城”轻，但比“管理系统”重，正好卡在答辩点
有人会问，那直接做个淘宝商城不更高级？问题在于复杂度。商城系统需要考虑支付网关对接、库存扣减并发、物流状态同步，这些一旦展开，就是一个完整商业项目的工作量，课设时间根本兜不住。二手交易平台不一样，它的每一单都是“一人一物一价”，没有 SKU、没有库存数、没有购物车结算这种复杂的联合逻辑，交易流程可以简化为“发布—沟通—拍下—完成”，逻辑清晰又完整。
从答辩角度讲，老师最喜欢问的几个问题也正好落在这个复杂度区间里：
- 你这个订单状态是怎么设计的，有哪些状态，怎么流转？
- 用户下单的时候，如果另一人先下了单，你怎么保证商品不会被重复卖？
- 图片是怎么存的？换一台电脑部署为什么图片还能正常显示？
- 拦截器是怎么做的？哪些接口需要登录才能访问？
这些问题说难不难，但确实需要有项目深度才能答得顺畅。把这篇文章后面几章看下来，这些问题基本都能接住。
2. 开发环境与依赖版本：90%的项目跑不起来，根因都在这一层
2.1 版本匹配是第一个真正的坑
很多同学拿到源码第一件事是用 IDEA 直接打开，然后 Maven 就开始疯狂下载依赖，最后报一堆看不懂的错。这里我先把最稳妥的版本组合列出来，你按这个来，能少走至少两天的弯路。
| 组件 | 推荐版本 | 原因说明 |
|---|---|---|
| JDK | 1.8（Java 8） | 市面上大量课设项目基于 JDK 8 开发，兼容性最稳，答辩机器也好配 |
| Spring Boot | 2.7.x | 2.x 时代生态资料最多，网上随便搜到的问题解决方案基本都是这个版本 |
| Maven | 3.6.3 及以上 | 太老的 Maven 可能解析不了 Spring Boot 父依赖 |
| MySQL | 5.7 或 8.0 | 5.7 最省心；如果必须用 8.0，JDBC 连接串要加时区参数 |
| IDEA | 2021.x 及以上 | 新版 IDEA 对 Maven 和 Spring Boot 的支持更友好 |
这里要专门提一句：如果你拿到的项目是基于 Spring Boot 2.x 的，不要手贱去升级到 3.x。Spring Boot 3 从 Java 17 起跳，很多老依赖的坐标和用法都变了，光是 javax 包改成 jakarta 就能让你多排查一整天。课设项目的目标是稳定跑通，不需要追新。
2.2 Maven 配置三件套
Maven 配置是最容易被忽略的环节，尤其是网络环境不好的时候，依赖下不动、下到一半断了、仓库里存了半截文件，全都会导致启动时报 ClassNotFoundException 或者莫名其妙的包冲突。我拿到新电脑配 Maven 的时候，固定做三件事：
第一件，改 Maven 镜像源。打开 Maven 安装目录下的conf/settings.xml，在<mirrors>里加一段：
<mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <name>Aliyun Maven Mirror</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>加完之后再到 IDEA 的 Settings -> Maven 里，把 User settings file 指向这个 settings.xml，并且确认 Local repository 路径没有包含中文字符。很多人项目跑不起来，纯粹是因为本地仓库路径里有中文或者空格，Maven 解析出错。
第二件，设置 IDEA 的编码。在 Help -> Edit Custom VM Options 里加一行：
-Dfile.encoding=UTF-8然后 Settings -> Editor -> File Encodings 里把 Global Encoding、Project Encoding、Default encoding for properties files 全部选成 UTF-8。这一步不做好，后面导入数据库时中文注释乱码、页面显示乱码，你还会以为是代码问题。
第三件，检查 Lombok 是否可用。课设项目里几乎必定用 Lombok（@Data那套），IDEA 需要安装 Lombok 插件并且在 Settings -> Build -> Compiler -> Annotation Processors 里勾选 Enable annotation processing。少了这一步，编译期看着很正常，一运行就报“找不到 getter/setter 方法”。
2.3 数据库导入的顺序与常见报错
环境配好、依赖拉完之后，下一步是导数据库。这个环节我见过太多人出错，集中表现为三种情况。
第一种，没建库直接导。正确顺序是先启动 MySQL，然后执行：
CREATE DATABASE IF NOT EXISTS campus_second_hand DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE campus_second_hand;建库语句执行完再导入.sql文件。如果你拿到的 SQL 脚本里自带CREATE DATABASE，那可以直接跳过手动建库，但要注意看脚本里的库名是否和application.yml里配置的一致，不一致照样报Unknown database。
第二种，MySQL 8.0 的时区问题。如果启动项目后报错：
The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized这就是时区导致的。在application.yml的 JDBC 连接串末尾加上serverTimezone=Asia/Shanghai就行，完整写法类似：
url: jdbc:mysql://localhost:3306/campus_second_hand?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai&useSSL=false第三种，Linux 环境下表名大小写敏感。这个坑在校验阶段最隐蔽。如果代码里查的是user表，但 SQL 脚本里建的是User，Windows 本地一切正常，Linux 服务器上就会报“Table doesn't exist”。要么统一全部小写，要么在建表脚本里保持大小写一致并配置lower_case_table_names=1（MySQL 8.0 在 Linux 上最好在建库前改，改完需要重启 MySQL）。
提示：导入 SQL 后，用 Navicat 或命令行的
SHOW TABLES;看一眼，确认表数量和数据行数都对得上，再启动项目。这一步 30 秒，能省后续排查一小时。
3. 数据库设计是整套系统的逻辑底盘
3.1 核心表结构与字段设计
说句实话，课设项目的后端代码只要照着 Controller -> Service -> Mapper 三层写，基本都能看懂，但数据库设计才是拉开档次的地方。校园二手交易平台最常见的设计是六张表：用户表、商品表、订单表、购物车表、收藏表、留言表。有些版本会有细微差别，比如用“收藏/关注”替代购物车，或者加一张商品分类表。不管哪种，核心关系是类似的。
用户表（user）：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | int | 主键自增 |
| username | varchar(50) | 用户名，唯一 |
| password | varchar(100) | BCrypt 加密后的密码串 |
| nickname | varchar(50) | 昵称 |
| phone | varchar(20) | 手机号 |
| avatar | varchar(255) | 头像路径 |
| role | int | 角色：0 普通用户，1 管理员 |
| create_time | datetime | 注册时间 |
商品表（goods）：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | int | 主键自增 |
| seller_id | int | 卖家 ID，关联用户表 |
| title | varchar(100) | 商品标题 |
| description | text | 详细描述 |
| price | decimal(10,2) | 售价 |
| original_price | decimal(10,2) | 原价或参考价 |
| category | varchar(50) | 分类：图书/数码/生活用品等 |
| images | varchar(1000) | 图片路径，多张用逗号分隔 |
| status | int | 状态：0 在售，1 下架，2 已售 |
| view_count | int | 浏览量 |
| create_time | datetime | 发布时间 |
订单表（orders）：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | int | 主键自增 |
| order_no | varchar(50) | 订单编号，唯一 |
| goods_id | int | 商品 ID |
| seller_id | int | 卖家 ID |
| buyer_id | int | 买家 ID |
| price | decimal(10,2) | 成交价 |
| status | int | 见下方状态机 |
| create_time | datetime | 下单时间 |
| finish_time | datetime | 完成时间（可空） |
留个言/消息表（message）的设计要点是：要有from_user_id、to_user_id、goods_id（可选，方便从商品页直接跳转到聊天）、content、create_time。它解决的是买卖双发站内沟通的问题，相当于把“贴吧留言”和“私聊”合在了一张表里。
3.2 状态字段为什么用 int 而不用字符串
这是答辩高频问题。商品状态和订单状态，很多同学喜欢在数据库里直接存字符串，比如status = '已付款'，查询显示倒是直白了，但坏处很多：一是中文状态没法做有效索引，二是业务代码里到处是魔法字符串，改一个状态文案要同时改数据库的存量数据；三是前端显示层和服务层耦合——数据库存的是给人看的文案，代码判断时就变得很奇怪。
项目里用 int 状态码，然后在代码里定义一个常量类，或者直接用枚举，才是正常的设计方式。比如订单状态我一般这样设计：
| 状态值 | 含义 | 说明 |
|---|---|---|
| 0 | 待确认 | 买家拍下，等待卖家确认（或等待买家付款） |
| 1 | 进行中 | 已确认，等待线下交付 |
| 2 | 已完成 | 交易闭环，双方确认完成 |
| 3 | 已取消 | 任意一方取消或超时取消 |
对应到代码里，就是一组常量：
public class OrderStatus { public static final int PENDING = 0; public static final int PROCESSING = 1; public static final int FINISHED = 2; public static final int CANCELED = 3; }这样 Controller 和 Service 里判断逻辑一读就懂：if (order.getStatus() == OrderStatus.CANCELED)，数据库里的数据也干净，业务扩展时加一个状态值就行，不用动存量数据。
3.3 外键到底要不要物理建
数据库设计时还有一个常见的纠结：要不要给外键加物理约束？我的建议是，课设项目完全可以用逻辑外键（也就是普通字段 + 索引），不要建物理外键。原因一是导入数据的时候物理外键对插入顺序有要求，非常容易报错；原因二是 MyBatis Plus 这种框架操作数据时，物理外键反而会影响一些批量操作；原因三是真实企业项目里物理外键用得也越来越少，面试时候你反而可以解释“用逻辑外键是为了保持高并发场景下的写入灵活性”。
但逻辑外键不是说不管关联，而是需要在关联字段上建索引。比如订单表的goods_id、seller_id、buyer_id都应该有索引，否则查询订单列表时全表扫描，数据一多就慢。实际执行可以这样：
ALTER TABLE orders ADD INDEX idx_seller (seller_id); ALTER TABLE orders ADD INDEX idx_buyer (buyer_id); ALTER TABLE orders ADD INDEX idx_goods (goods_id);这一点做好了，答辩时老师问“你这系统数据量大怎么办”，你就能直接说：核心查询字段建了索引，并对订单按用户维度进行了索引覆盖。
4. 核心功能模块实现思路：不是所有代码都叫 CRUD
4.1 注册登录：密码加密是底线中的底线
有个别同学为了图省事，注册时直接把密码明文存进数据库，登录时把用户输入的密码select * from user where username=? and password=?查一遍。这样确实能跑通，但这属于项目里最大的硬伤，答辩被问到“密码安全怎么处理”会非常尴尬。正确做法是使用BCryptPasswordEncoder，Spring Security 框架里自带这个工具类，单独引进来用也行。用法很简单：
// 注册时加密 BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(); String encodedPassword = encoder.encode(user.getPassword()); user.setPassword(encodedPassword); // 登录时校验 boolean matches = encoder.matches(rawPassword, user.getPassword());这样做的一个好处是，就算数据库被导出了，别人拿到的也是一串不可逆的密文，原始密码不会被泄露。
登录之后的会话保持，课设项目通常用 Session 就够了，也就是登录成功后把用户 ID 或用户对象放进 Session，然后写一个拦截器对需要登录的接口做校验。如果项目做了前后端分离（比如前端是 Vue），那就用 JWT 更合适，但课设里大多数是 Spring Boot 直接渲染页面，Session 方案最简单、也最好演示。
4.2 商品发布与图片上传：路径设置的坑最多
商品发布功能一般包括表单提交 + 图片上传。图片上传的代码很多教程有，最容易被忽略的是存储路径。如果直接把图片保存成绝对路径，比如D:/upload/xxx.jpg，然后存进数据库，项目一旦换一台电脑部署，路径全废，所有图片全部加载不出来。这是个非常典型的问题，因为课设项目经常要在不同机器上演示。
我建议的做法是：在配置文件里定义一个自定义属性，存的是上传根目录的相对位置，然后用 Spring Boot 的静态资源映射把它暴露出去。示例配置如下：
app: upload-dir: ./upload/@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Value("${app.upload-dir}") private String uploadDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadDir); } }这样上传的图片保存到项目运行目录下的upload/文件夹，数据库里只存相对路径/upload/xxx.jpg，前端渲染时直接拼上域名和上下文路径就能访问。换电脑部署时，只要把整个项目目录拷过去、保证./upload/存在即可。
文件上传的接口里要顺手做两件事：校验文件类型和后缀（只允许jpg、png等常见图片格式），限制文件大小（比如 2MB）。别小看这一步，不限制的话，一个超大文件就能耗尽你的本地磁盘资源。
4.3 商品搜索、分类筛选与分页
商品列表页要支持按关键词模糊搜索、按分类筛选、按价格排序、分页显示。这个功能如果用 MyBatis Plus 自带的能力，可以写得很简洁。核心是用LambdaQueryWrapper构造查询条件：
LambdaQueryWrapper<Goods> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Goods::getStatus, 0) .like(StringUtils.hasText(keyword), Goods::getTitle, keyword) .eq(StringUtils.hasText(category), Goods::getCategory, category) .orderByDesc(Goods::getCreateTime); Page<Goods> page = goodsMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);这里最关键的一个点：搜索的时候一定要加上status = 0（在售）这个条件，否则下架商品和已售商品会一起出现在列表里。这个问题我在验收同学代码时见过太多次了，看起来只是少加了一个eq，但整个列表页的逻辑就错了。
分页插件如果要生效，别忘记在配置里加 MyBatis Plus 的分页拦截器：
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }不加这个返回的Page对象里records会一直是全部数据，分页等于没分。这也是一个常见的“代码看着对，跑起来不对”的坑。
4.4 订单流程与并发控制：防止同一件商品被卖两次
订单模块是这个项目最有含金量的地方。下单操作不能只是一个简单的insert，因为这里存在一个天然的并发问题：一件商品，如果两个买家几乎同时下单，怎么办？如果代码是“先查状态，状态为 0 再更新”这种两步操作，那就存在间隙，两个请求可能同时查到状态是 0，然后都执行下单成功，商品就卖重了。
课设级别的合理解法是在更新商品状态时加上条件，用原子操作解决：
@Transactional public boolean createOrder(Order order) { // 先把商品从“在售”改成“已售”，只允许 status=0 成功 int updated = goodsMapper.update(null, new LambdaUpdateWrapper<Goods>() .eq(Goods::getId, order.getGoodsId()) .eq(Goods::getStatus, 0) .set(Goods::getStatus, 2)); if (updated == 0) { // 抢不到，说明商品已被下单或下架 return false; } // 更新成功才插入订单 orderMapper.insert(order); return true; }这段逻辑的关键在于update ... where id=? and status=0，数据库的行锁会保证同一时刻只有一个请求能改状态，另一个请求更新影响行数为 0，直接返回失败。这样代码又短又安全，而且答辩时非常好解释——你用的是“乐观锁思想”，不是那些听起来很高深但很难实现的分布式锁。
需要注意的事务问题：@Transactional默认只捕获 RuntimeException 回滚，如果orderMapper.insert抛的是 checked exception，事务不会回滚。所以下单这种场景，代码里最好只抛运行时异常，或者在注解上显式指定rollbackFor = Exception.class。
4.5 管理后台：拦截器与权限控制
管理员功能一般比较直白：商品管理、用户管理、订单管理、数据统计。但这里有一个很容易被导师挑刺的点——权限控制不能只在页面上隐藏入口，后端接口同样要拦住。你不能让一个普通用户通过直接访问/admin/deleteUser的 URL 就能把用户删了。
实现方式是写一个拦截器，注册时只放行登录接口、注册接口、商品列表和详情等公开接口，其余接口都检查 Session 里有没有用户；管理员相关的接口再检查role是否为 1。示例结构：
@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("user"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }通过注册配置，把拦截器作用在/admin/**和需要登录才能访问的路径上。这个设计简单有效，也是课设项目里“权限控制”的标准答案。
5. 调试部署的完整链路：从源码压缩包到云服务器上线
5.1 本地跑通项目的正确顺序
拿到源码后，我的建议是按照下面这个顺序逐步推进，不要跳步，也不要一上来就点 Run：
- 先读项目根目录的 README 或部署文档，看清数据库脚本位置、默认账号密码、启动端口；
- 建好数据库并导入 SQL 脚本，确认表和数据都正确；
- 修改
application.yml里的数据库账号密码、端口号等； - 用 IDEA 打开项目，等待 Maven 依赖解析完毕，观察没有报错；
- 启动启动类里的
main方法，看控制台日志是否输出了Tomcat started on port(s): 8080； - 浏览器访问
http://localhost:8080，用项目自带的管理员账号登录后台。
如果前面环境配置都做对了，这六步一般半小时就能走完。一旦卡住，先看控制台日志的最后三行，绝大多数报错原因都会比较明显。
5.2 本地调试中最高频的坑
这里把我遇到过的高频问题整理成一张表，每一条都是真实场景里反复出现的。
| 现象 | 根本原因 | 解决要点 |
|---|---|---|
Access denied for user 'root'@'localhost' | yml 里的数据库账号密码不对 | 检查application.yml的 username/password 是否和本地 MySQL 一致 |
Unknown database | 库名写错或库没建 | 用CREATE DATABASE建库，核对库名 |
Communications link failure | MySQL 服务没启动 | Windows 下启动 MySQL 服务，或确认端口 3306 没被占用 |
Port 8080 was already in use | 端口被其他程序占用 | 换端口：server.port=8081，或关掉占用进程 |
Cannot load driver class: com.mysql.cj.jdbc.Driver | mysql-connector 没引入或版本不对 | 在 pom.xml 检查依赖，确认版本和 Spring Boot 兼容 |
Whitelabel Error Page | 页面路径映射错误或 Controller 返回的视图不对 | 检查 Controller 的返回字符串和templates下的页面文件名是否匹配 |
| 数据库中文乱码 | 连接串编码不对或数据库字符集不对 | 连接串加characterEncoding=utf-8，建库用utf8mb4 |
5.3 打包部署到云服务器的过程
本地跑通了，接下来要部署到服务器上。先打包：
mvn clean package -DskipTests这里如果不加-DskipTests，Maven 会去跑单元测试，很多课设项目里测试类其实是空的，没必要额外浪费时间。打包完成后，target目录会生成一个可执行的xxx.jar，这个 JAR 就是整个后端应用。
把 JAR 包上传到服务器后，在服务器上执行：
nohup java -jar campus-second-hand-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod > app.log 2>&1 &nohup配合&是为了让应用退出 SSH 之后继续运行。日志输出到app.log，后续排查问题直接看这个文件。启动完成后，用tail -f app.log观察日志，看到 Tomcat 端口启动成功，就说明部署没问题了。
5.4 部署到服务器后最容易忽略的三件事
第一，安全组端口要开。云服务器有个由安全组控制的防火墙，你得在控制台把 8080 端口（或者你自定义的端口）加入放行规则，否则外面访问不了。
第二，数据库不要直接暴露公网。如果你用的是云数据库，尽量让后端应用通过内网连接；如果你用的是服务器本地 MySQL，就不要在安全组里开放 3306 端口。只有后端服务的 8080 端口需要开放。有些同学图方便，把 3306 也开放了，结果服务器被扫库攻击、数据被删，这类教训在安全新闻里经常看到。
第三，生产环境配置要改。application.yml里如果开发环境开了spring-boot-devtools热部署，打包部署时一定要注释掉或者用 profile 区分，否则服务器上会有意外重载。数据库密码、密钥等信息不要在配置里写明文，可以用环境变量覆盖。
6. 答辩前做这几个改造，项目档次直接高一截
6.1 用一个接口文档，让老师看到你的工程化思维
很多同学把代码跑通就觉得完事了，但答辩时最尴尬的瞬间是，老师想看某个接口返回什么，你在 browser 里手忙脚乱地输 URL。我的建议是加一个 Swagger（Springfox 或 springdoc 都行），让所有接口自动生成联机文档。
在 Spring Boot 2.x 里用 springdoc 的路径很顺，加依赖后在配置文件里开启，启动项目访问http://localhost:8080/swagger-ui.html，能看到每个 Controller 的请求方式、参数说明和返回结构。这一招在答辩现场的效果远好于贴代码，老师会觉得你具备基本的工程规范和自查能力。
6.2 加一层 Redis 缓存，应对“性能优化怎么做”这个问题
“性能优化”是老师必问的题。校园二手交易平台首页的商品列表、热门分类这些数据是热点数据，完全可以在 Service 层加一层缓存。引入 Redis 后，查询商品列表时先查缓存，命中就直接返回；没有命中才查数据库，然后回填缓存并设置过期时间。
课设里你不一定要真的把 Redis 用得多深，只需要说明这个思路、再写一个简单的 Service 层缓存逻辑，就能证明你理解缓存是什么、为什么缓存能扛高并发读。答辩时老师问“如果这个系统用户量涨了十倍怎么办”，你就可以回答：读多写少的场景，优先用 Redis 做缓存，商品详情这一类热点数据可以设置短过期时间，同时把搜索热词也做缓存。这一套回答下来，已经能覆盖大部分期待了。
6.3 把图片从本地存储改成云存储
如果项目时间还有富裕，建议把图片上传从本地目录迁移到 OSS 或七牛云这类对象存储。改造思路不复杂：上传接口接收到文件后，直接把文件流交给云存储 SDK，云存储会返回一个 URL，数据库里存这个 URL，页面加载图片时直接走 CDN。
这个改造的收益非常大，因为它同时解决了三个课设常见问题：换机器图片丢失、本地磁盘压力、外网访问慢。而且答辩时你还能顺带解释“为什么真实项目中不用本地存储”，因为需要水平扩展、图片访问要 CDN 加速、存储要和应用服务器解耦。哪怕代码没有完全跑通，把这个设计讲清楚，老师也会认为你理解到了生产环境的要求。
6.4 答辩常被追问的问题清单
最后把我这几年听到的高频提问列一下，提前准备，避免现场卡壳：
- Spring Boot 的自动配置原理是什么？为什么写一个
main方法就能启动应用？ - 为什么密码要用 BCrypt？MD5 有什么问题？（答案重点是：MD5 加彩虹表可反查，BCrypt 自带盐且计算成本可调）
- 数据库表为什么会这么设计？有没有冗余？第三范式你了解吗？
- 商品列表的分页是怎么实现的？为什么自定义分页 SQL 时数据库方言很重要？
- 拦截器和过滤器有什么区别？你的权限控制为什么选拦截器？
- 如果用户同时下单，你怎么保证不超卖？你用到了事务，事务隔离级别是什么？
- 这个项目如果部署到线上，你觉得最大的风险是什么？（可以回答：防盗链、图片恶意上传、接口防刷）
这些问题在本文对应的章节基本都有答案，建议看完之后自己对着代码再走一遍，做到不用翻笔记也能讲清楚。
最后再分享一个小技巧。拿到任何一套 Spring Boot 项目，先别急着打开代码，花二十分钟把三个东西看完：数据库脚本、application.yml配置、启动类和拦截器注册类。这三样是项目的“地图”，看懂了它们，你对整套系统的理解会比 80% 的同学都深。这个顺序不仅适用于这套校园二手交易平台，也适用于你以后实习、工作中接手任何一套陌生代码库，亲测有效。希望你顺利跑通，顺利答辩。
