Spring Boot整合Hadoop：校园二手交易系统毕设项目实战拆解-平芜编程栈

校园二手交易这个场景，在每年的毕业设计里几乎都是TOP3的热门选题。但大多数人的项目都停留在"SSM+JSP+MySQL"这种十年前的技术栈上，答辩时老师一问分布式就哑火。今天要拆解的这个项目比较特别：Java Spring Boot做后端业务层，Hadoop HDFS做文件存储层，把一套标准的校园二手交易系统做出了大数据项目的味道。项目自带源码、文档、运行视频和讲解视频四项交付物，既能跑通完整交易闭环，又能体现Hadoop分布式存储的整合能力，在毕设和简历两个战场上都能打。

这篇我会从整体架构拆解、核心功能实现、部署运行复盘、答辩亮点准备到常见坑位排查，完整过一遍这套系统的设计思路和实操细节。如果你是打算选这个题目的同学，或者想学Spring Boot怎么整合Hadoop的开发者，这篇文章应该能把你从"看过"带到"跑通"再到"能讲清楚"。

1. 项目整体定位与核心需求拆解

1.1 校园二手交易的真实痛点

先说业务层。校园里的二手交易和闲鱼、转转这种全品类平台有很大区别，最大的特点是"信任半径小"——买卖双方大概率在同一个校区，交易可以当面验货、面对面交付。这意味着系统不需要做很重的物流、支付和售后体系，但必须把"校内身份"和"交易撮合"这两件事做好。

这个项目的核心业务模型围绕四个角色展开：普通学生用户（发布商品、购买商品）、管理员（审核商品、管理用户）、访客（浏览商品）、系统本身（负责订单状态流转）。业务闭环从发布闲置开始，经过搜索浏览、商品详情、下单购买、确认收货，到最后双方互评结束，是一条非常标准的C2C交易链路。

1.2 为什么选Spring Boot + Hadoop这个组合

我拆过很多类似项目，发现选型逻辑大致分两条路线：一条是纯业务路线，用Spring Boot + MyBatis + MySQL + Redis + Vue，把CRUD做漂亮，业务功能堆得很满；另一条是纯大数据路线，用Flume+Kafka+Spark写一堆离线统计，但业务系统本身很虚。

这个项目取了中间节奏，用Spring Boot保证业务系统足够完整，再把文件存储层从本地磁盘切到Hadoop HDFS。这个选择的聪明之处在于：它让项目同时覆盖了Web后端和大数据存储两块知识体系，答辩时能展开讲的点比纯CRUD项目多一倍。而且图片这类非结构化数据存HDFS，从架构合理性上讲也说得通——分布式存储天然适合大量小文件的横向扩展。

1.3 这套交付物对三类人群的价值

这套"源码+文档+运行视频+讲解视频"的完整交付包，对三类人尤其有用。第一类是正在准备毕业设计、但时间被实习和论文两头挤压的学生，跑通一个现成项目再针对性改造是最稳的路径；第二类是技术和业务都想沾边的Java开发初学者，系统本身代码风格规范，Hadoop整合部分可以作为企业级项目的敲门砖；第三类是准备转行大数据开发、但作品集里没有Web项目支撑的求职者，这个项目可以同时证明Web后端和HDFS读写两方面的工程能力。

2. 技术栈全景与核心原理分析

2.1 系统技术架构分层

整套系统从访问入口到数据存储，可以清晰拆成三层。表现层用Vue（或Thymeleaf，取决于具体前端方案）渲染页面，通过RESTful API与后端通信；业务层由Spring Boot承担，负责用户认证、商品管理、订单流转、评论等所有核心逻辑；数据层则拆成两块——关系型数据落MySQL，非结构化文件（商品图片、用户头像）落HDFS。

这个分层最关键的决策点是"数据双写"：用户发布商品时，表单信息写入MySQL的goods表，图片文件通过HDFS Java API写入分布式文件系统，数据库里只保存HDFS返回的文件路径。读取商品详情时，前端通过后端提供的文件流接口去HDFS拉图，而不是直接拼一个本地磁盘路径。

2.2 HDFS在系统里扮演的角色

HDFS在这个项目里不是摆设，它承担的是"商品图片仓库"的职责。传统的单机项目会把图片存到项目的static目录或单独的图片服务器，但遇到磁盘空间不足、图片需要迁移备份、并发上传量增大这几类问题时，单机存储就可能成为瓶颈。HDFS通过数据块复制和自动负载均衡，把文件分散到多个DataNode上，对应用层来说是透明的一个命名空间——上层代码只需要关心路径和文件流，底层文件落在哪块磁盘上完全不用管。

项目使用的是Hadoop伪分布式模式，即在单台机器上同时启动NameNode、DataNode和SecondaryNameNode进程，模拟一个最小规模的Hadoop集群。这种模式对毕业设计场景来说已经足够：它展示了完整的HDFS读写流程、元数据管理机制和Shell命令操作，又不需要真的去搭三台以上节点的集群。

2.3 版本匹配选型的避坑指南

版本匹配是Hadoop项目最容易翻车的第一道关，必须认真对待。拿到这个项目源码后，第一步就是确认三个版本的兼容性：JDK版本、Spring Boot版本和Hadoop版本。

组件	推荐版本	说明
JDK	1.8	Hadoop 3.x完全兼容，Spring Boot 2.x默认构建目标
Spring Boot	2.5.x ~ 2.7.x	稳定且与hadoop-client依赖无冲突
Hadoop	3.3.x	伪分布式部署简单，Java API稳定
MySQL	5.7 或 8.0	8.0需注意驱动版本和时区配置
MyBatis-Plus	3.5.x	简化CRUD，配合Spring Boot 2.x很顺手

这里特别提醒一个容易踩的坑：Hadoop生态的hadoop-client依赖体积很大，会传递引入一堆Zookeeper、Netty等底层库。如果Spring Boot版本和Hadoop版本冲突，启动时常见报错是NoSuchMethodError或类冲突，这往往不是代码问题，而是Hadoop传递依赖把Spring Boot里的某个类覆盖了。解决思路是手动排除冲突的依赖，或者直接复刻原项目的POM文件版本，不要自创组合。

2.4 核心配置：HDFS连接信息

Spring Boot整合HDFS，本质上就是通过FileSystem对象操作分布式文件系统。原项目的核心配置一般长这样：

# hdfs.properties hdfs.uri=hdfs://localhost:9820 hdfs.user=root

配套的Java配置类负责创建单例的FileSystem实例：

@Configuration public class HdfsConfig { @Value("${hdfs.uri}") private String hdfsUri; @Bean public FileSystem fileSystem() throws IOException { Configuration conf = new Configuration(); conf.set("fs.defaultFS", hdfsUri); // 伪分布式下副本数必须设为1，否则会一直上报副本不足 conf.set("dfs.replication", "1"); return FileSystem.get(URI.create(hdfsUri), conf); } }

这段配置里最容易出错的是端口号。Hadoop 2.x的NameNode RPC端口是9000，Hadoop 3.x换成了9820。如果项目用的是Hadoop 3.x但配置里还是旧端口，连接时会直接超时或报Connection refused。拿到源码后第一时间核对core-site.xml里的fs.defaultFS和Java配置里的URI保持一致。

3. 功能模块设计与数据库建模

3.1 用户角色与权限设计

系统的用户体系分为普通用户和管理员两种角色。普通用户注册后可以浏览、发布、编辑、下架自己的商品，可以下单购买别人的商品，可以收藏、评论、评价订单；管理员有独立的后台入口，可以审核待上架商品、下架违规商品、管理用户状态、查看交易统计数据。

权限控制这块，项目用的是JWT（JSON Web Token）方案。用户登录成功后，后端签发一个包含用户ID和角色信息的Token，前端在后续请求的Header里携带Token，后端通过Spring MVC拦截器统一校验。不需要登录就能访问的接口（比如首页商品列表、商品详情）在拦截器配置里放行，需要身份的接口（发布商品、下单）则强制校验。Session和JWT的选择上，JWT更适合当前前后端分离的趋势，也方便在答辩时讲出"无状态认证"这个关键词。

3.2 核心业务功能梳理

整个系统的业务功能可以按"用户端"和"管理端"两个视角来梳理。

用户端核心功能清单：

用户注册、登录、个人信息维护、头像上传
商品发布（标题、描述、价格、成色、分类、多张图片）
商品列表浏览（分页、按分类筛选）
商品搜索（关键字匹配标题和描述）
商品详情页（图片、卖家信息、留言列表）
收藏商品、取消收藏
下单购买、订单状态跟踪（待付款/已付款/已发货/已完成/已取消）
订单确认收货、双方评价
个人中心（我发布的、我买到的、我卖出的、我收藏的）

管理端核心功能清单：

用户管理（查看、禁用/启用）
商品管理（审核待上架商品、下架违规商品）
分类管理（增删改商品分类）
基础数据统计（商品总数、用户总数、订单总数、近七日交易量）

3.3 数据库表结构设计

数据库设计的合理性直接决定了后期改功能的成本。这个项目的表设计基本覆盖了C2C交易系统的标准模型，核心表如下：

user：用户表，字段包括用户名、密码（加密存储）、昵称、头像路径、角色（0普通用户/1管理员）、状态、创建时间
category：商品分类表，字段包括分类名、排序、状态
goods：商品表，字段包括标题、描述、价格、成色、图片地址（存HDFS路径）、分类ID、卖家ID、状态（0待审核/1在售/2已下架/3已售出）、浏览量、创建时间
orders：订单表，字段包括订单号、商品ID、买家ID、卖家ID、成交价格、状态（0待付款/1已付款/2确认收货/3已取消）、创建时间、完成时间
favorites：收藏表，字段包括用户ID、商品ID、创建时间
comment：评论表，字段包括商品ID、用户ID、内容、创建时间

需要专门说明的是goods表里的图片地址字段。因为是"文件和业务数据分离存储"，这个字段存的是HDFS路径，比如/goods/images/20240115/uuid_iphone11.jpg，读取时由后端拼完整的HDFS URI再返回文件流。这种设计在答辩时是很好的切入点——可以向老师解释"为什么不直接存图片二进制到MySQL"，答案很明确：MySQL存大文件会拖慢数据库性能、增加备份负担，而HDFS天然的横向扩展能力适合海量小文件的存储。

3.4 HDFS目录结构规划

文件存储不能一窝蜂全塞到根目录，必须按业务类型规划目录结构。原项目的HDFS目录大致如下：

/goods/ # 根目录 ├── /goods/images/ # 商品图片 ├── /goods/avatar/ # 用户头像 └── /goods/backup/ # 备份文件

利用HDFS Shell命令可以直接创建目录：

hdfs dfs -mkdir -p /goods/images hdfs dfs -mkdir -p /goods/avatar

这样规划的好处是，后续做定期清理或按目录分析数据时，一条hdfs dfs -du -h命令就能看到每个目录的占用情况，方便答辩时展示你对HDFS文件管理的理解。

4. 核心功能模块的落地实现

4.1 开发环境准备与Hadoop伪分布式部署

在跑项目代码之前，先把"地基"打好。我的建议是先装好Java和Maven，再部署Hadoop伪分布式，最后导入Spring Boot项目。

Hadoop伪分布式部署的关键步骤：

下载Hadoop 3.3.x压缩包，解压到干净目录
配置etc/hadoop/core-site.xml，设置fs.defaultFS为hdfs://localhost:9820
配置etc/hadoop/hdfs-site.xml，设置副本数dfs.replication为1
配置Java环境变量对应的JAVA_HOME
格式化NameNode：hdfs namenode -format（第一次必须做）
启动HDFS：执行start-dfs.sh，然后jps命令检查三个进程是否都活着

这里有一个必须说清楚的细节：伪分布式模式下副本数必须设为1。因为单个节点上只有一个DataNode，副本数是3的话，HDFS会一直报Under-Replicated Blocks，文件明明上传成功了，Web UI上却显示块副本不足，很容易让初学者误以为系统坏了。

我在实际部署中遇到过的情况是，很多人搞不清"格式化NameNode"和"启动"的顺序，或者改了配置之后重新格式化导致NameNode和DataNode的clusterID不一致，DataNode一直起不来。如果你的DataNode进程闪退，优先看日志文件，十有八九是VERSION文件里的clusterID对不上，把两边的clusterID改成一致的再重启DataNode就行。

4.2 用户认证与权限控制

用户注册时，密码不能明文入库，项目里用的是BCrypt加密工具，这是Spring Security内置的哈希算法，每次加密结果随机但校验时能正确匹配。这块不需要自己造轮子，直接调用BCryptPasswordEncoder的encode和matches方法即可。

用户登录成功后，后端构建一个JWT字符串返回给前端。JWT里包含三个部分：Header（声明算法）、Payload（用户ID、用户名、角色）、Signature（用密钥签名）。实际代码里封装一个JwtUtil工具类，提供createToken和parseToken两个核心方法。前端把Token存在localStorage或Cookie里，每次请求通过Axios请求拦截器自动加到Header的Authorization字段。

后端拦截器要处理的逻辑也不复杂：放行登录注册接口和商品查询接口，拦截需要身份认证的接口。校验Token失败统一返回401状态码，前端收到401后再跳转登录页。这个"前端拦截器+后端拦截器"的双层防护，是答辩时值得提一嘴的设计。

4.3 商品发布与HDFS文件上传

商品发布是整个系统里最核心、最值得展开讲的功能，因为它是Spring Boot业务逻辑和Hadoop HDFS存储结合的桥头堡。

前端表单提交时携带商品信息和图片文件，后端Controller接收MultipartFile数组后，处理逻辑分四步：

第一步，遍历上传的图片文件，校验类型和大小（通常在Controller层或配置层做限制）；第二步，调用封装好的HdfsService，把图片写入HDFS指定目录，文件名用UUID加上原始文件名拼接，避免重名覆盖；第三步，拿到HDFS返回的路径后，连同商品表单信息一起插入MySQL数据库；第四步，如果MySQL插入失败，需要把已经上传到HDFS的图片删除掉，保证数据一致性。

HdfsService里最核心的写入逻辑类似这样：

public String upload(MultipartFile file, String dir) throws IOException { String filename = UUID.randomUUID().toString().replace("-", "") + "_" + file.getOriginalFilename(); Path hdfsPath = new Path(dir + "/" + filename); // HDFS写入流 try (FSDataOutputStream out = fileSystem.create(hdfsPath, true)) { out.write(file.getBytes()); out.flush(); } return dir + "/" + filename; }

图片回显是很多新手卡住的地方：商品详情页需要展示图片，但如果前端直接拼hdfs://localhost:9820/goods/images/xxx.jpg这种地址是访问不了的，因为HDFS的RPC协议不是HTTP，浏览器没法直接请求。所以后端必须再提供一个读取文件流并回写HTTP响应的接口：

@GetMapping("/api/file/load") public void loadFile(@RequestParam String path, HttpServletResponse response) throws IOException { Path hdfsPath = new Path(path); try (FSDataInputStream in = fileSystem.open(hdfsPath); OutputStream out = response.getOutputStream()) { // 按字节流拷回给前端 byte[] buffer = new byte[4096]; int len; while ((len = in.read(buffer)) != -1) { out.write(buffer, 0, len); } } }

这个"上传走HDFS、读取走Spring Boot流代理"的设计，是整条文件链路的精髓。面试官或答辩老师如果追问"HDFS文件怎么在前端展示"，这个接口就是把球接住的关键。

4.4 商品检索与交易状态机

商品检索分两种场景：一种是通过分类标签浏览，也就是categoryId直接查goods表；另一种是关键字搜索，用LIKE模糊匹配标题和描述。这个项目没有引入Elasticsearch，因为校园二手场景的数据量单机MySQL完全扛得住，一个复杂的LIKE查询已经能覆盖需求。如果你在答辩时被问到"为什么不用ES"，可以坦诚回答：当前的数据规模和并发量下MySQL足够，引入ES是过度设计，但架构上已经预留了替换空间——搜索引擎重构成独立模块并不难。

订单状态机是整个业务系统里逻辑最复杂的部分。一个订单的生命周期包含这么几个状态：待付款、已付款、待确认收货、已完成、已取消。状态流转有严格的约束，比如只有"待付款"状态才能取消订单，只有"已付款"状态才能确认收货。代码里的做法一般是用一个整数状态字段配合switch或状态模式做流转校验，禁止非法跳转。

订单状态的每次变化都推荐记录在订单表里，同时更新商品的销售状态。商品一旦被下单，就要从"在售"改成"已售出"，避免同一件商品被多人重复下单。这个"一单锁一货"的逻辑在并发量不高的情况下用事务加行锁就能解决，Spring Boot里直接给下单方法加@Transactional注解，让MySQL的行锁保证数据安全。

4.5 管理员后台与数据看板

管理员的商品审核流程是这样的：用户发布商品后，商品状态默认为"待审核"，管理员登录后台看到待审核列表，可以操作"通过"或"驳回"。通过后商品才出现在前台列表里。这个流程用代码实现不复杂，无非就是修改商品状态字段。

数据看板是管理员后台比较加分的一个模块，通常用图表展示几项核心指标：商品总数总量、用户注册趋势、近7日订单量、商品分类分布。这些统计数据的来源都是MySQL，通过简单的GROUP BY和日期条件聚合就能算出来，用ECharts把数据渲染成折线图、饼图、柱状图。这部分功能技术难度不高，但视觉效果好，答辩演示时能很快抓住老师的关注点。

5. 部署运行与配套材料使用指南

5.1 拿到交付物后的正确打开顺序

这套项目带"源码+文档+运行视频+讲解视频"四项材料，很多人的用法是直接打开源码开始看，这其实是效率最低的路径。我的建议是按照"运行视频→文档→源码→讲解视频"的顺序来推进。

第一步花10分钟完整看一遍运行视频，记录系统有哪些页面、哪些功能、界面长什么样。这个过程是在建立"目标图景"，后面所有操作都围绕复现这个图景展开。第二步打开文档，重点看环境搭建和部署说明，把所有需要安装的软件的版本号记下来，逐个安装配置。第三步导入源码，先不急着读代码，而是把项目跑起来，对照运行视频逐项验证功能。最后再结合讲解视频去理解核心模块的代码实现，这时候代码是从"看得懂"变成"讲得出"。

5.2 一套亲测可行的启动顺序

跑通环境是这套项目落地最容易出问题的环节，我整理一下常见可行的启动顺序：

启动MySQL服务，执行项目文档提供的init.sql脚本，完成建库和初始化数据
启动Hadoop HDFS，执行start-dfs.sh，用jps验证NameNode、DataNode进程都在
修改项目配置文件application.yml里的数据库账号密码和HDFS URI，确保指向本机启动的服务
启动Spring Boot应用，观察控制台日志，确认没有报错
打开前端页面或浏览器访问后端地址，用管理员账号登录后台，用普通用户账号测试完整交易流程

启动顺序的核心原则是"依赖提前"：Spring Boot依赖MySQL和HDFS，所以数据库和分布式文件系统必须先起来。如果说前端需要独立的Vue服务器，还需要再启动一个npm run serve进程。前后端分离模式下，后端接口的CORS跨域配置必须在启动前就确认好，否则前端页面调接口时会直接失败。

5.3 讲解视频里的重点模块标注

讲解视频一般会覆盖系统演示和核心代码讲解两个部分。看的时候建议带着问题去听，不要被动接收。我根据经验列出几个值得重点关注的模块，也是答辩时被追问概率最高的知识点：

HDFS工具类的封装思路：为什么用单例模式？上传下载删除三个方法各是什么签名？
JWT拦截器的放行规则：哪些接口需要认证？如果不用拦截器改用Spring Security会有什么差异？
商品发布的事务边界：MySQL插入和HDFS上传之间的数据一致性怎么保证？如果HDFS写入成功但MySQL失败，怎么回滚？
订单状态机：状态字段为什么用整数？非法状态流转是怎么拦截的？
分页查询的实现：用MyBatis-Plus的Page对象还是手写LIMIT？排序字段怎么动态传入？

带着这些问题去看讲解视频，把答案用自己的话整理出来，到了答辩现场会非常从容。

6. 常见问题与避坑指南

6.1 Hadoop启动失败类问题

这类问题在伪分布式部署中极其常见，我把典型的症状、原因和解决办法整理成速查表。

症状	常见原因	解决方案
`jps`看不到DataNode	NameNode格式化后clusterID不一致	删除HDFS临时目录下的`VERSION`文件，重新格式化或手动统一clusterID
NameNode启动后自动退出	`dfs.namenode.name.dir`配置的目录不存在	确认目录存在且当前用户有读写权限
端口被占用	9820端口被其他进程占用	`lsof -i:9820`查看占用进程，释放端口或改端口
启动时提示`JAVA_HOME`错误	Hadoop的`hadoop-env.sh`里没配Java路径	在`hadoop-env.sh`里显式设置`JAVA_HOME`
`hdfs dfs -ls`报Connection refused	伪分布式服务没启动或端口不对	确认`start-dfs.sh`已执行，检查URI端口是否为`9820`

6.2 HDFS文件上传与读写异常

文件上传是HDFS集成最核心的操作，一旦报错排查优先看日志堆栈的底层异常类型。最常见的几类：

身份认证类异常，报错内容是Permission denied: user=xxx, access=WRITE。这是因为本地操作系统的用户名和HDFS上的用户不一致。解决办法是在Java代码里显式指定HDFS操作用户，也就是配置hdfs.user参数，在FileSystem.get时传入用户身份，或者给HDFS目录开放写权限。

连接超时异常，报错内容是Failed on local exception: java.net.ConnectException。如果客户端代码不在Hadoop部署的同一台机器上，需要检查是否配置了正确的fs.defaultFS地址，以及客户端机器能不能通过ping和telnet访问服务端IP。虚拟机模式开发时一定要用虚拟机的内网IP，不能用localhost。

空间不足异常，报错内容是There is insufficient space for the allocation。多数情况下是虚拟机磁盘空间不够，HDFS默认存副本会导致文件实际占用翻倍。检查方式是用df -h看磁盘，再用hdfs dfs -du -h /看HDFS已用空间，清理一些不需要的文件或调大虚拟机的磁盘分配。

6.3 Web层配置问题

问题一：上传图片超过大小限制。Spring Boot默认的spring.servlet.multipart.max-file-size是1MB，一张手机拍的实拍图经常超过这个值。需要在application.yml里调大，比如设置成20MB，同时设置max-request-size为50MB。如果忘记调大，前端传图时会报FileSizeLimitExceededException，这是一个特别容易排查的低级问题，真实面试中却经常有人在系统演示时被它绊倒。

问题二：跨域请求被拦截。如果前端用Vue独立端口跑，后端必须开启CORS配置。Spring Boot里可以写一个CorsFilter，允许指定来源的跨域请求，或者使用@CrossOrigin注解直接加到Controller上。跨域没配好时，浏览器控制台会报CORS policy: No 'Access-Control-Allow-Origin' header，但后端日志看不到任何异常，这个特性很容易让人误判问题方向。

问题三：HDFS图片路径回显404。数据库里存的路径是/goods/images/xxx.jpg，前端页面需要的是完整可访问的URL。如果后端loadFile接口接收的是相对路径，需要拼接hdfs.uri前缀再创建Path对象，否则会提示文件不存在。

6.4 答辩现场的高分答题角度

论文答辩和找工作面试的底层逻辑是相通的：你需要向对方证明"我做的东西有复杂度，且我完全理解它"。这个项目里天然埋了几个可以重点展开的话题：

第一个话题是"为什么引入Hadoop"。对应答案是：图片等非结构化数据量持续增长，单机磁盘存储无法弹性扩展，使用HDFS可以做分布式存储，通过数据块副本机制保证可靠性。这个回答既体现"你是主动做技术选型的"，也体现"你理解分布式存储的核心价值"。

第二个话题是"为什么图片不存MySQL而存HDFS"。对应答案是：MySQL擅长结构化数据的索引和事务，但大字段存取耗资源、拖慢性能；HDFS是大规模文件的天然归属地，读文件流的方式适合图片这类一次写入多次读取的数据。这个回答能体现你对存储组件边界划分的思考，是加分项。

第三个话题是"系统能不能支撑高并发"。对应答案是：当前架构下单机Spring Boot能支撑校园级并发，但如果需要扩容，Spring Boot侧可以横向扩展节点，HDFS本身天然支持横向扩展，MySQL可以引入读写分离或分库分表。不需要真的测出QPS数据，把扩容路径说清楚，老师就能感受到你把系统当作可以演进的产品来对待，而不是作业。

第四个话题是"如果重新做一次会怎么改进"。这个问题的回答思路可以从架构演进角度展开：引入Redis做高频商品缓存和验证码存储，引入消息队列削峰下单请求，引入Elasticsearch做商品全文检索，引入Docker Compose一键部署环境。这些"升级路线"不需要真的在系统里实现，说清楚动机和预期的效果就够了。

7. 一些踩过坑之后才总结出来的心得

拆了不少类似项目，带过不同基础的同学跑环境、改代码、准备答辩，最大的感受是：这套系统最大的价值不在"功能多"，而在于它把Web后端和大数据存储这两件本来在课程里是两门课的东西，在动手实现层面拧在了一起。很多同学单说Spring Boot CRUD说得头头是道，单独理解HDFS的架构原理也能背得出来，但一到了"上传文件到HDFS，再把路径存MySQL，最后回显时从HDFS拉流"这条完整链路上，就会暴露认知断层。也因此，凡是认真跑通过一遍这个闭环的人，简历上面试官再问"你理解文件系统和数据库怎么协作吗"这类问题，答起来是带的出真实经验感的，不是背八股。

最后分享一个小技巧：拿到任何毕设项目的源码，第一件事不要急着在IDE里点运行，而是先把原项目里的application.yml、pom.xml和数据库初始化脚本这三个文件完整读一遍。这三个文件是整个系统技术栈的最浓缩表达。搞清楚版本号、端口、数据库账号、文件路径这些"地基参数"，再上人手做任何改动，都会踏实很多。祝你们都能把这套系统跑得顺、讲得清，答辩不慌。

Spring Boot整合Hadoop：校园二手交易系统毕设项目实战拆解