企业官网建设流程全解析

简介：基于Spring Boot的校园闲置物品交易网站项目，包含完整源码、数据库脚本、设计文档和答辩PPT，适合计算机类专业学生用于课程设计、毕业设计或Java Web开发练习。系统覆盖前台商品浏览、购物车、个人中心，以及后台用户、商品类型、商品信息、订单和系统管理等模块，并区分管理员与普通用户两类视角，结构清晰，有助于理解Spring Boot与MySQL的整合开发思路。同时前台商品资讯、收藏管理与购物车流程均完整实现，功能贴近校园闲置物品交易场景。资源包为zip压缩包，共785个文件，大小25.37MB，主要文件类型包括Java源文件、Vue前端组件、JavaScript脚本、CSS样式、HTML页面、SQL数据库脚本和XML配置等，其中Java文件负责后端业务，Vue与JS/CSS处理前端交互，SQL脚本可初始化数据，另附带一键安装与运行脚本，便于快速启动演示。目前已有44人学习下载，资源内容完整、目录明确，既支持按模块阅读源码，也可直接作为毕业设计课题进行二次功能扩展，整体上手门槛较低。

1. SpringBoot校园闲置物品交易网站：这份源码包能解决什么

校园二手交易这个场景，信息常年散落在微信群和QQ群里，没有上下架状态、没有交易闭环，纠纷来了也找不到人。基于SpringBoot的校园闲置物品交易网站（源码+数据库+文档+PPT），就是把这套流程搬进系统：学生注册登录、发布闲置、浏览搜索、下单购买、留言沟通，管理员在后台管理商品和用户。

对正要交毕业设计或课程设计的人来说，它的价值不只是“能跑”，更是一份把源码、数据库、文档、答辩PPT四样东西对应起来的完整交付物。适合三类人：时间紧、想快速跑通并改动出自己作品的学生；想拿二手交易练手但不想从零搭建工程的后端学习者；需要给老师或甲方做完整演示的技术人员。这里不讨论业务推广，只讲怎么把它读明白、改得动、跑得稳。

2. 技术栈与项目结构：SpringBoot项目结构怎么读、怎么改

2.1 为什么是SpringBoot单体架构——校园场景下的合理选型

校园闲置交易这个需求有一个很明显的特点：使用人数少、并发低、功能边界清楚。一个学校几千人注册已经算不错了，真正同时在线可能不到一百。对这种规模，SpringBoot单体应用就是性价比最高的答案——一个可执行的jar包，MySQL做存储，前端由模板渲染或静态页面承担，部署在一台普通服务器上就能撑起整个业务。

市面上这类源码包绝大多数是SpringBoot框架 + MyBatis（或MyBatis-Plus）+ MySQL 的组合。原因不难理解：SpringBoot把配置自动化，不用像SSH那样写一摞XML；MyBatis让你能把SQL攥在自己手里，遇到范围查询、多表关联，写起来比JPA直观；MySQL则是不需要论证的默认选择。这套组合在毕业设计里占据了压倒性比例，参考资料最多，出了问题也最容易搜到答案。

前后端分离的问题要单独说一下。有些源码包用Vue做前端，跑起来要先npm install再打包，构建产物放到src/main/resources/static目录下随SpringBoot一起发布，这就是“vue打包放进springboot中”的常见做法。另一些直接用Thymeleaf或JSP。拿到一个包后，我不会急着启动，而是先看pom.xml，确认它是哪种形态。如果是Vue那套，要检查node_modules是否附带、打包脚本是否齐全；如果是模板渲染，就省事得多。这个判断决定了后续改前端功能的成本。

2.2 源码目录的五层结构：拿到包后先读这五个目录

先看整体目录。一个标准的SpringBoot工程长这样，包名和项目名可以不同，但层次结构大同小异：

springboot-campus-secondhand/（示意结构） ├── src/main/java │ └── com/example/{你的包名} │ ├── controller # 接收请求，返回视图或JSON │ ├── service # 业务逻辑，事务边界 │ ├── mapper # MyBatis接口，和XML绑定 │ ├── entity # 数据库表对应的实体类 │ └── config # 配置类，拦截器、资源映射 ├── src/main/resources │ ├── mapper # MyBatis的SQL XML文件 │ ├── static # 前端静态资源 │ ├── templates # 模板页面（如果有） │ └── application.yml # 核心配置文件 ├── sql/ # 数据库初始化脚本 └── pom.xml # 依赖与版本管理

读源码的顺序我一般建议：pom.xml → application.yml → sql目录 → resources/mapper → controller和service。前三个决定你能不能跑起来，后两个决定你会不会改。新手最常见的误区是直接打开Controller开始读，读到一半发现调用了某个service方法，再跳到service，又发现SQL在XML里，来来回回把思路全打乱了。其实只要按数据流向读，先看请求进来打到哪个controller，再看它调了哪个service，最后落到哪条SQL，整条链路就清楚了。

这套源码包的“Database”部分一般会在sql目录里，文档可能叫docs或者doc，PPT通常是一个单独文件。先把这三样东西找出来，项目读起来会快很多，也能提前发现缺失项，免得最后答辩前才发现文档和代码对不上。

2.3 启动配置：application.yml里必须改的3个参数

打开源码包后第一个要动的地方是application.yml，最常见的版本长这样：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_secondhand?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 5MB max-request-size: 20MB file: upload-dir: D:/upload/

第一个必改参数是server.port。默认8080非常容易和本地其他Java服务、Nginx或IDE自带服务冲突，启动直接报端口占用。我会把它改成8081或8082，避免每次跑项目都要先关别的进程。

第二个必改参数是spring.datasource.url。serverTimezone=Asia/Shanghai不能省，MySQL 8.x不指定时区会直接报错；characterEncoding=utf8决定中文能不能正常读写。驱动类名必须和pom.xml里的MySQL依赖版本对应，8.x写com.mysql.cj.jdbc.Driver，5.x写com.mysql.jdbc.Driver，混用就会ClassNotFound。

第三个是file.upload-dir，图片上传的保存目录。很多源码包把路径写死在Java代码里，换一台机器就报“找不到目录”。我一般会把它改成配置项，并且指向一个独立目录，比如Linux下的/data/upload。这样项目重打包、换机器都不用动代码。数据库账号密码如果不改，至少要确认不是本机的root密码，否则启动时数据库连不上，页面全是500。

3. 数据库设计与初始化：五张核心表和一份能跑的SQL

3.1 实体关系：先理顺用户、商品、订单、留言之间的关系

打开sql目录里的初始化脚本，不要急着执行，先把表关系理一遍。校园闲置交易网站的核心实体有五个：分类、用户、商品、订单、留言。分类和商品是一对多，用户和商品是一对多，用户通过商品产生留言，订单则同时关联买家、卖家、商品三个对象，是整张关系网里最复杂的部分。

这套系统表面上是“首页展示商品”，本质还是数据库增删改查的编排，只是表之间多了一层状态关联。我见过不少源码包五张表互相没有外键约束，全靠Java代码硬查，执行倒是能执行，数据一乱就追不到源头。拿到表结构之后，先看两件事：主键是不是自增、删除是不是逻辑删除。逻辑删除是这类项目的主流做法——商品被管理员下架只改status字段，用户投诉记录也不做物理删除，因为答辩时老师会问“用户纠纷怎么追溯”，物理删除在这个场景下是减分项。

3.2 建表SQL：用户表和商品表的字段取舍

用户表是最简单也最容易埋坑的一张表，商品表则承载了大部分查询压力。先看两张核心表的建表脚本：

CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL COMMENT '登录名', `password` VARCHAR(100) NOT NULL COMMENT '加密后的密码', `nickname` VARCHAR(50) DEFAULT NULL, `phone` VARCHAR(20) DEFAULT NULL, `role` TINYINT DEFAULT 0 COMMENT '0普通用户，1管理员', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `goods` ( `id` INT NOT NULL AUTO_INCREMENT, `user_id` INT NOT NULL COMMENT '发布者id', `category_id` INT DEFAULT NULL, `title` VARCHAR(100) NOT NULL, `description` TEXT, `price` DECIMAL(10,2) NOT NULL DEFAULT 0.00, `status` TINYINT DEFAULT 0 COMMENT '0在售，1已下架，2已卖出', `image_url` VARCHAR(255) DEFAULT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

字段取舍上两个点值得说明。一是password字段：老源码包很多直接存明文密码，数据库一旦泄露所有账号裸奔。即使是最简单的方案，也应该用MD5加盐再存；如果项目里已经集成了Spring Security，直接换BCrypt。二是price用DECIMAL(10,2)而不是FLOAT：浮点数在比较和计算时会出精度问题，答辩时被问到“两件商品总价算出来不对”会非常尴尬。商品表的status字段是整张表的重点，上架、下架、卖出都由它控制，后续所有前台查询都要带着status = 0做条件。

3.3 订单表与留言表：用status字段把交易状态机写清楚

订单表是交易系统的灵魂，留言表则承担了买卖双方沟通的职能：

CREATE TABLE `orders` ( `id` INT NOT NULL AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL COMMENT '订单号', `goods_id` INT NOT NULL, `seller_id` INT NOT NULL, `buyer_id` INT NOT NULL, `price` DECIMAL(10,2) NOT NULL, `status` TINYINT DEFAULT 0 COMMENT '0待付款，1待收货，2已完成，3已取消', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `pay_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表'; CREATE TABLE `comment` ( `id` INT NOT NULL AUTO_INCREMENT, `goods_id` INT NOT NULL, `user_id` INT NOT NULL, `content` VARCHAR(500) NOT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='留言表';

订单状态用数字不用字符串，主要是可扩展性：将来要加“退款中”，TINYINT加一个枚举值就行，不用改表结构。另一个好处是统计效率，GROUP BY status可以直接算出各状态订单数量，写进文档里就是现成的图表数据。状态流转方向要有约束：0→1→2 是正向，任意状态→3 是取消，但 2 不能回退到 1。这种约束放在Java代码里容易漏，理想做法是service层每次更新前先查当前状态，不匹配就抛异常。order_no设置唯一索引是为了防重复订单，生成策略一般用时间戳加随机数，不要用自增ID当订单号——订单号外露会让别人猜到你的总订单量。

3.4 初始化数据：管理员账号、分类和演示数据怎么导

普通用户注册之后页面上没有商品，整个系统看起来是空的。所以sql脚本里会预留三类数据：一个管理员账号、5到8个商品分类、几条演示商品。执行顺序是先建库，再建表，最后INSERT：

mysql -uroot -p -e "CREATE DATABASE campus_secondhand DEFAULT CHARSET utf8mb4;" mysql -uroot -p campus_secondhand < sql/init.sql

Windows命令行下执行要注意文件路径的斜杠方向。更常见的报错是中文变成问号，解决方法是确认三处字符集：建库语句用utf8mb4、JDBC连接串带characterEncoding=utf8、MySQL服务端本身的character_set_server也得对得上。三处不一致，数据就一定会乱。管理员账号一般是admin/admin123，首次登录后记得改密码。演示数据不要造太多，商品图片的URL路径必须真实可访问，否则首页加载一堆破图，答辩印象分会掉得很快。

4. 核心功能实现：把源码包里的四块硬骨头啃下来

4.1 登录拦截：拦截器注册与放行路径的取舍

校园交易网站天然区分普通用户和管理员。最原始的做法是在Controller每个方法里判断session，这样既容易漏、代码也难看。成熟的源码包会用拦截器统一处理，核心代码长这样：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object userId = request.getSession().getAttribute("userId"); if (userId == null) { response.sendRedirect("/login"); return false; } // 管理员接口额外校验角色，通过自定义注解标记 if (handler instanceof HandlerMethod && ((HandlerMethod) handler).hasMethodAnnotation(AdminOnly.class)) { Integer role = (Integer) request.getSession().getAttribute("role"); if (role == null || role != 1) { response.setStatus(403); return false; } } return true; } }

拦截器写完后，注册时最关键的是excludePathPatterns：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/goods/list", "/goods/detail/**", "/css/**", "/js/**", "/images/**"); } }

这段配置的逻辑是：所有路径默认拦截，登录、注册、商品浏览和静态资源放行。/css/**、/js/**、/images/**这三组放行特别容易漏，漏了之后页面样式全没，只剩下纯HTML，新手经常误判为前端代码坏了。/goods/list放行是因为商品列表属于公开信息，没登录应该能看；但下单接口绝对不能放行。给管理员的删除、审核接口加一个@AdminOnly注解，用hasMethodAnnotation判断要比在拦截器里写死路径清单优雅得多，也符合Spring的注解驱动风格。

4.2 商品发布与图片上传：本地存储与静态资源映射

商品发布页通常带一个图片上传框。实现方案很多，最省事的是保存到本地磁盘，再把访问URL写入数据库：

@Value("${file.upload-dir}") private String uploadDir; @PostMapping("/goods/publish") public String publish(@RequestParam("title") String title, @RequestParam("price") BigDecimal price, @RequestParam(value = "image", required = false) MultipartFile image) throws IOException { String imageUrl = null; if (image != null && !image.isEmpty()) { String originalFilename = image.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String filename = System.currentTimeMillis() + "_" + new Random().nextInt(1000) + ext; File dest = new File(uploadDir, filename); image.transferTo(dest.getAbsoluteFile()); imageUrl = "/upload/" + filename; } // service层保存商品信息，imageUrl入库 return "redirect:/goods/list"; }

这段代码有两个细节。生成文件名不能直接用用户上传的原始文件名，否则两个用户上传同名图片会互相覆盖，时间戳加随机数是新手最容易漏掉的一环。/upload/是虚拟访问路径，物理文件在D盘或/data目录，浏览器不能直接访问磁盘路径，所以必须加静态资源映射：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadDir); }

file:前缀不能丢。很多源码包在这一步翻车：上传成功、图片在磁盘上存在、但浏览器就是404，原因就是只写了addResourceHandler而忘了addResourceLocations。另一个坑是uploadDir末尾要带分隔符，Windows下是D:/upload/，Linux下是/data/upload/，少了斜杠启动时可能报路径不存在。上传目录千万不能放在src/main/resources下面，打包成jar之后这个目录是只读的，图片根本写不进去。

4.3 下单与并发：update ... where status = 0 的并发安全写法

商品下单最怕两个问题：同一件商品被两个人同时下单、同一用户重复下单。两种情况的根源都是“先查再改”，查和改之间存在时间差。简单的处理方式是把检查动作合并到UPDATE语句里：

@Service public class OrderService { @Transactional public void createOrder(Long goodsId, Long buyerId) { // 1. 尝试把商品从“在售”改成“已卖出”，影响行数为0说明商品已被买走 int updated = goodsMapper.markSold(goodsId); if (updated == 0) { throw new BusinessException("商品已下架或已被买走"); } // 2. 生成订单号并插入订单记录 String orderNo = "GO" + System.currentTimeMillis(); Goods goods = goodsMapper.selectById(goodsId); ordersMapper.insert(Order.builder() .orderNo(orderNo) .goodsId(goodsId) .sellerId(goods.getUserId()) .buyerId(buyerId) .price(goods.getPrice()) .status(0) .build()); } }

对应的Mapper SQL写在XML里：

<update id="markSold"> UPDATE goods SET status = 2 WHERE id = #{goodsId} AND status = 0 </update>

UPDATE ... WHERE status = 0是数据库层面的原子操作，两条并发请求同时进来时，只有一条能更新成功，另一条影响行数为0，直接抛业务异常。这比“先SELECT再UPDATE”的方案安全得多，也更容易在答辩时讲清楚。这里必须配合@Transactional，否则订单插入成功但商品状态没更新，数据就不一致了。要注意Spring的@Transactional默认只在抛出RuntimeException时回滚，所以自定义异常BusinessException最好继承RuntimeException，不要用检查异常。orderNo直接用了时间戳，高并发下有极小概率重复，实际项目可以加一个Redis自增序列，但毕设场景不需要过度设计。

4.4 商品搜索与分页：MyBatis-Plus分页插件的标准写法

首页商品列表和后台商品管理都需要分页。如果源码包用了MyBatis-Plus，分页写起来非常简洁：

public Page<Goods> searchGoods(String keyword, Integer categoryId, Integer pageNum, Integer pageSize) { Page<Goods> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Goods> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Goods::getStatus, 0) .like(StringUtils.hasText(keyword), Goods::getTitle, keyword) .eq(categoryId != null, Goods::getCategoryId, categoryId) .orderByDesc(Goods::getCreateTime); return goodsMapper.selectPage(page, wrapper); }

Page对象的pageNum和pageSize会直接作为SQL的LIMIT参数，pageNum从1开始。条件字段用LambdaQueryWrapper而不是字符串拼SQL，最大的好处是字段名写错会在编译期暴露，同时杜绝了用户输入拼接进SQL的注入风险。StringUtils.hasText(keyword)表示关键字为空时不加这个条件，分类ID同理。这段代码跑通后，整个项目的列表页逻辑就基本通了，后台管理页只要去掉eq(Goods::getStatus, 0)再翻一翻排序条件就行。

5. 部署避坑与常见问题：从“跑不起来”到“环境弄坏”的5条血泪记录

每次帮人排查这类SpringBoot校园二手项目，遇到的问题翻来覆去就是那几个，这里按“现象→原因→解决”记录，碰到直接对照。

5.1 端口被8080占用导致启动失败

现象：启动日志最后一行报Port 8080 was already in use，应用进程立即退出，页面完全打不开。

原因：本地有另一个Java服务、Nginx或其他开发工具占用了8080端口，SpringBoot默认端口撞车。这不是代码问题，是环境问题。

解决：优先改端口而不是杀进程。在application.yml里把server.port改成8081或8082，或者启动时用--server.port=8081临时指定。如果必须用8080，再找占用进程序号：Windows用netstat -ano | findstr 8080查PID，Linux用lsof -i:8080。注意不要一上来就杀掉所有Java进程——你本地可能同时跑着好几个SpringBoot服务，锁定了端口对应的PID再判断。

5.2 MySQL驱动和SpringBoot版本不匹配的ClassNotFound

现象：启动时抛ClassNotFoundException: com.mysql.jdbc.Driver，或者连接时提示Unable to load authentication plugin 'caching_sha2_password'。

原因：老源码包里的MySQL驱动还停留在5.x时代，驱动类名是com.mysql.jdbc.Driver，而本机装的是MySQL 8.x，认证插件和驱动类名都变了。反过来还有一种情况——SpringBoot版本太高，默认引入的驱动和你的老数据库不兼容。

解决：打开pom.xml，把mysql-connector-java的版本升到8.0.x，并把application.yml里driver-class-name改成com.mysql.cj.jdbc.Driver。连接串补上serverTimezone=Asia/Shanghai。升级驱动后如果还报认证插件错误，在连接串里加allowPublicKeyRetrieval=true，这是本地开发环境的标准做法，生产环境应该靠SSL处理。

提示：改完MySQL驱动后一定要同时改pom.xml和application.yml两处，只改一处就会在启动时报类不存在或参数不匹配，这两处是配套的。

5.3 中文乱码不是玄学，是三层编码没对齐

现象：插入商品标题变成“???”，或数据库里看中文正常但页面上显示乱码。

原因：三层字符集不一致——建库时不是utf8mb4、JDBC连接串没带characterEncoding、IDE终端本身不是UTF-8。只要有一层不齐，中文就保不住。

解决：按顺序排查。先查库：SHOW CREATE DATABASE campus_secondhand，如果不是utf8mb4就执行ALTER DATABASE ... DEFAULT CHARACTER SET utf8mb4；再改连接串加useUnicode=true&characterEncoding=utf8；最后检查IDE的File Encoding设置成UTF-8。Windows上从网盘解压的源码，Java和XML文件经常被系统改成GBK，页面输出就是乱码。数据库里已经写脏的数据，删除重导比一条条UPDATE省事得多。这套排查顺序能解决九成以上的乱码问题，剩下一成是MySQL服务端本身的character_set_server配置，用SHOW VARIABLES LIKE 'character_set_server'一眼就能确认。

5.4 上传图片404：静态资源映射和物理路径对不上

现象：上传图片时没有报错，数据库里也有URL，但浏览器访问图片地址返回404，或者首页图片全是裂图。

原因：上传代码里保存路径是D:/upload/，而静态资源映射的目录是/data/upload/，两者不一致；或者页面里的img地址写的是/upload/xxx.jpg，但代码中addResourceHandler映射成了/img/**。

解决：把上传路径和映射路径统一。最稳的做法是file.upload-dir配置项和addResourceLocations("file:" + uploadDir)指向同一个绝对路径，并且都用/结尾。改完后如果还是404，打开浏览器开发者工具看图片请求的完整URL，对照WebConfig里的addResourceHandler定义，基本都是两边的路径不匹配，没有例外。

5.5 加了@Transactional却还是写了半截数据

现象：商品状态更新成功，但订单插入失败抛异常，页面报错后重新查数据，发现商品已经变成已卖出，订单却没有生成。

原因：事务没生效。最典型的是同类内部调用——OrderService的createOrder调用了同一个类里的另一个方法，这个内部调用绕过了Spring的AOP代理，@Transactional直接失效。另一个常见原因是异常被try-catch吞掉了，事务管理器看不到异常自然不会回滚。

解决：把事务方法拆到另一个Bean里，让外部Bean调用内部Bean的public方法；或者用TransactionTemplate手动控制。异常处理上，如果业务必须捕获异常，记得在catch块里重新抛出RuntimeException，或者用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()强制回滚。这一点属于Spring AOP的黑匣子行为，光看代码很难发现，出现这种半截数据基本就是它。

6. 进阶：让这份源码包从“能跑”变成“能答辩的水平”

6.1 文档和PPT怎么写出亮点：三张图讲清一个项目

大多数毕业设计的文档通病是“需求分析写一大堆，设计图一张没有”。老师最想看的其实就三张图：ER图、交易流程图、部署架构图。ER图可以用Navicat逆向数据库自动生成，把五张表的关系连出来再润色；流程图就用订单状态机的四个状态画一个闭环；部署图画浏览器、SpringBoot、MySQL三条线。PPT控制在12页以内，每页只讲一个重点。下单时那段UPDATE ... WHERE status=0的代码放大放上去，比贴满整页代码有说服力得多。

6.2 给项目加一个加分项：定时任务和WebSocket提醒

如果嫌这个项目太常见，加一个功能点就能拉开差距。第一个选择是定时任务：用Sping的@Scheduled每天凌晨把超过30天未卖出的商品自动下架，一个注解加一个service方法就能实现。第二个选择是用WebSocket在买家下单时给卖家推一条实时提醒，前端保持连接，下单接口里向卖家会话发送消息。两个方向都不难，但都能自然写进文档的创新点，老师问起来也讲得清楚。

6.3 一个工程习惯：拿到任何源码包，先跑起来再改

最后说一个我自己踩坑踩出来的习惯。拿到一个不熟悉的SpringBoot二手交易源码包，不要急着打开IDEA改代码，更不要直接删掉某个报错的类。先把数据库脚本导入，把项目跑起来，注册一个账号，完整走一遍“发布商品、搜索、下单、留言”的流程。跑通之后，再带着一个具体的问题去断点跟代码，比如“下单成功之后商品状态是在哪一行变的”。这个顺序能让你在最短时间内摸清项目的骨架和状态流转。答辩前至少完整演示三遍，尤其是图片上传和订单状态变化这两处，最容易现场翻车。希望这次梳理的启动顺序和坑位能帮你少走几段弯路，也祝你顺利把这份源码变成自己的东西。

本文还有配套的精品资源，点击获取