每年六月底的毕业季宿舍楼下都会堆满教材、台灯、自行车和收纳箱这些九成新的东西最后大多论斤卖给了收废品师傅到了九月份新生入学又有人花几十上百元买回同款教材。这两拨人之间的信息鸿沟就是校园二手交易平台存在的意义。最近我把这套Spring Boot Vue实现的校园二手交易平台完整整理了一遍前后端分离架构附带完整源代码和万字详设文档。这篇文章就从项目定位、技术选型、数据库设计、核心功能实现到部署运维把整个项目拆开讲清楚。不管是拿来做毕业设计、课程设计还是想真正在校内跑一套二手交易系统都有直接可抄的参考价值。先说项目能做什么。用户端支持注册登录、商品发布、图片上传、分类浏览、关键字搜索、商品详情、收藏、下单、个人中心管理管理端支持用户审核、商品审核、分类维护、订单管理、公告管理和基础数据统计。整个系统覆盖了二手交易的核心闭环发布-曝光-沟通-交易-售后。技术上用的是Spring Boot提供RESTful接口Vue负责页面渲染和交互数据通过JSON交互前后端完全解耦。1. 校园二手交易平台的真实痛点与功能边界1.1 为什么校园闲置交易不能直接套用闲鱼方案我在设计这套系统之前先对着校园场景盘了一遍需求。很多同学第一反应是直接用闲鱼不就行了吗但真放在校园环境里这几个问题绕不开第一信任半径不同。闲鱼的交易双方是陌生人靠芝麻信用和平台担保校园里面的买卖双方大概率是同一所学校甚至同一个校区的学生交易核心是确认这个人确实是本校学生而不是泛化的信用体系。所以系统里要有学生认证的环节管理端能审核用户身份这比复杂的信用模型实在。第二交易方式差异明显。校园二手交易大多是线下当面交易约在食堂门口、宿舍楼下一手交钱一手交货。这意味着订单状态设计不能完全照搬电商的待付款-待发货-待收货-待评价那套更合理的状态是待面交-已完成-已取消物流环节可以整个去掉。第三商品品类的季节性特别强。开学季教材需求集中爆发毕业季宿舍清仓量大平时则是小家电、数码配件、体育用品零零散散。分类设计上要预留足够灵活的调整空间管理端必须有分类管理功能不能把分类写死在代码里。第四商品展示的本地属性。多数学生不会花心思写长描述、拍专业照片所以发布表单要尽量简化图片支持多张上传描述给个200字以内就够重点把价格、成色、交易地点这几个字段做得明显。1.2 系统角色与功能模块划分基于上面的分析这套系统把用户分成三类角色角色核心权限主要页面普通用户发布商品、浏览搜索、收藏、下单购买、个人中心首页、商品列表、商品详情、发布页、订单页、个人中心平台管理员用户管理、商品审核、分类管理、订单管理、公告管理后台工作台、用户列表、商品审核列表、分类管理页超级管理员管理员账号管理、数据权限配置系统管理相关页面普通用户走前台管理员走独立后台前后台在同一个工程里通过路由和权限控制做隔离。权限控制这块用最简单可靠的方案后端接口基于JWT解析用户身份和角色前端路由配置守卫判断登录状态和角色双端校验避免前端隐藏菜单但接口照样能调的常见漏洞。功能边界上我刻意做了一些减法。比如不做即时聊天买家和卖家之间通过平台留言或订单备注交换联系方式不做在线支付面交场景下支付动作发生在站外不做复杂推荐算法商品排序用发布时间和热度两个基础维度。减法的逻辑很简单校园二手场景的核心是信息匹配不是交易担保把不必要的功能砍掉系统才能稳定跑起来、代码才能真正被读透。2. 技术选型逻辑Spring Boot 3 Vue 3 前后端分离的依据2.1 后端选择Spring Boot的核心原因后端框架我选了Spring Boot而不是SSH或者纯Servlet写法理由很直接Spring Boot解决了Java后端开发里最烦人的配置问题。传统SSM框架要手动配置web.xml、applicationContext.xml、spring-mvc.xml光是让一个项目跑起来就要花半天时间Spring Boot通过自动配置和starter机制把大部分重复性配置直接封装掉。以本项目的依赖为例引入spring-boot-starter-web就搞定了内嵌Tomcat、Spring MVC、JSON序列化三大件引入mybatis-plus-boot-starter就搞定了数据库访问层。对于这种中小型管理系统Spring Boot的开发效率比SSM高出一倍不止。选择Spring Boot还有一个实际考量内置Tomcat让部署变得极其简单。项目打包成可执行的jar包服务器上只要装了JDK就能直接java -jar运行不需要单独安装配置Tomcat。这在后面前后端分离项目的部署环节会体现得非常明显我们照样能把前端dist目录放进去一起跑也能拆出来单独部署非常灵活。Spring Boot 3.x是当前的主流版本基于JDK 17内嵌Tomcat 10整体性能和新特性支持都更好。如果考虑兼容性和周边生态比如某些老版本的MyBatis-Plus依赖适配问题选2.7.x也完全够用。项目里核心差异不大无非是javax包名改成jakarta这类细节。2.2 前端为什么用Vue以及版本取舍前端部分用Vue是现阶段做中小型管理系统的默契选择。Vue的渐进式设计让它上手门槛明显低于React一个懂HTML和JavaScript的同学花一周时间就能写页面同时组件化机制保证了中后台页面这种表格表单弹窗的高重复度界面能高度复用。版本选择上我推荐Vue 3 Vite Element Plus的组合。Vue 3的Composition API在逻辑复用上比Vue 2的Options API清晰得多以商品列表页为例加载状态、分页参数、搜索条件、列表数据这些响应式状态可以独立维护不用把所有方法都堆在methods里。Vite的冷启动速度和热更新体验相比webpack是代际提升npm run dev几乎是秒开。Element Plus是Element UI的Vue 3版本表格、表单、弹窗、分页这些后台常用组件都有现成的而且样式比老版本更清爽。有个容易被忽略的问题是前端node_modules的安装。Vue 3 Vite的依赖树比较大网络不好时npm install容易失败。我的实操建议是优先用npm官方源装不上就换国内镜像源具体命令npm config set registry https://registry.npmmirror.com。还有Vite对Node版本有要求Vite 4以上需要Node 14.18Vite 5需要Node 18开发前先node -v确认一下不然跑起来就是各种莫名其妙的报错。2.3 前后端分离架构的收益和数据交互约定前后端分离不是赶时髦它解决的是实际协作和维护问题。前端只负责渲染和交互后端只负责提供数据接口两边可以并行开发只要接口约定提前定好。在校园二手平台这个项目里我定义了几条核心约定所有接口前缀为/api返回结构统一为{code, message, data}日期时间统一用时间戳或格式化字符串传输避免时区混乱分页参数统一用pageNum和pageSize。这套约定的价值在联调阶段才会真正体现。前后端同学照着同一个接口文档走前端Mock数据跑通页面后端用Swagger或Postman自测接口最后联调时把前端的Mock地址切换到真实地址即可。我在文档里专门把每个接口的请求方式、参数、返回示例都列清楚了就是为了减少联调阶段的返工。3. 从商品发布到订单完成数据库设计与状态流转3.1 用户、商品、订单三大核心表的设计要点数据库设计是整个项目的根基表结构设计不合理后面写代码全是补丁。我按业务实体把表拆成七张用户表、商品表、订单表、分类表、收藏表、评论表、公告表。其中用户表、商品表、订单表是绝对核心我把关键字段和设计意图列一下。用户表核心字段id、username、password加密存储、nickname、avatar、role0普通用户/1管理员、student_no学号、status0禁用/1正常、create_time。密码加密我用的BCrypt这是Spring Security自带的加密算法每次加密结果带随机盐就算数据库泄露也不能直接反推出明文密码。学号字段是学生认证的关键管理员在后台核对学号信息完成认证。商品表核心字段id、user_id发布者、category_id、title、description、price用DECIMAL类型避免浮点精度问题、images多个图片URL用逗号拼接、degree成色全新/几乎全新/轻微使用痕迹/明显使用痕迹、status0待审核/1在售/2已下架/3已售出、view_count、create_time。这里有个实战细节images字段我用逗号分隔存储单条记录虽然不够范式化但省去了建图片子表的复杂度查询时直接split就能拿到图片列表对图片数量固定且不多1-5张的场景足够用。订单表核心字段id、order_no订单编号、product_id、buyer_id、seller_id、price、contact_info联系方式、deal_location交易地点、status0待面交/1已完成/2已取消、create_time、finish_time。设计要点是同时存了买家和卖家ID查询我买到的和我卖出的都不需要关联查询商品表再来判断身份直接查两个字段就行。order_no用时间戳加随机数生成保证唯一性。剩下的表里分类表设计成两级结构parent_id字段指向父分类收藏表和评论表都以商品ID作为外键逻辑关联。3.2 商品状态与订单状态的状态机设计状态机是交易类系统的灵魂状态设计得好业务代码写起来就是几个if判断的事情设计得乱到处都是互相矛盾的状态赋值。商品状态我定义了四个0待审核、1在售、2已下架、3已售出。状态流转只有几条固定路径发布时进入待审核管理员审核通过后进入在售在售状态下用户可手动下架变为已下架已下架商品重新上架则回到在售订单创建后商品变为已售出。订单状态对应三条路径用户提交订单后进入待面交买家确认收货或者双方线下交易完成并在平台确认后变为已完成在待面交状态下双方任意一方取消则变为已取消。这里有个容易踩坑的地方商品状态和订单状态必须联动。下单成功时商品要同步变成已售出否则会出现商品已经卖了还在在售列表里的脏数据。这个联动我放在服务层用Transactional注解包裹保证两个状态的更新要么都成功要么都回滚。3.3 事务处理在交易流程中的落地以用户提交订单为例代码逻辑看起来只是插入一条订单记录实际上牵扯到三步操作校验商品状态必须是1在售、插入订单记录、修改商品状态为已售出。这三步必须在一个事务里完成。Service public class OrderServiceImpl implements OrderService { Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateVO vo, Long buyerId) { // 1. 校验商品状态 Product product productMapper.selectById(vo.getProductId()); if (product null || product.getStatus() ! ProductStatus.ON_SALE) { throw new BusinessException(商品不存在或已下架); } // 2. 插入订单记录 Order order new Order(); order.setOrderNo(OrderNoGenerator.generate()); order.setProductId(product.getId()); order.setBuyerId(buyerId); order.setSellerId(product.getUserId()); order.setPrice(product.getPrice()); // ... 其他字段 orderMapper.insert(order); // 3. 修改商品状态为已售出 productMapper.updateStatus(product.getId(), ProductStatus.SOLD); return order.getId(); } }注意Transactional注解默认只在RuntimeException时回滚所以rollbackFor要显式设为Exception.class否则遇到受检异常时事务不会回滚数据库里就会留下一半数据。这个坑我在早期写SSM项目时踩过一次后来所有涉及多表更新的方法都统一写成rollbackFor Exception.class。4. 后端核心实现细节鉴权、文件上传与分页查询4.1 JWT登录鉴权与拦截器配置登录鉴权我用JWT 拦截器的方式实现没有引入Spring Security全家桶原因是对这种中小型系统来说Spring Security的过滤器链配置复杂度远大于它带来的安全收益JWT本身已经够用。流程是这样的用户登录成功后服务端生成一个包含用户ID和角色的JWT令牌返回给前端。JWT的payload是三段式的Header.Payload.Signature结构服务端用秘钥对Payload签名客户端拿到Token后每次请求放在请求头里服务端拦截器校验签名和有效期即可。关键代码逻辑Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、注册等白名单接口 if (handler instanceof HandlerMethod false) { return true; } String path request.getRequestURI(); if (path.contains(/api/user/login) || path.contains(/api/user/register)) { return true; } // 从请求头中获取Token并校验 String token request.getHeader(Authorization); if (StringUtils.hasText(token) JwtUtils.verify(token)) { // 把用户信息放入Request作用域供Controller直接使用 request.setAttribute(userId, JwtUtils.getUserId(token)); return true; } // 校验失败返回401 response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write(JSON.toJSONString(new Result(401, 登录状态已失效请重新登录))); return false; } }拦截器配置好之后还有一个容易忽略的细节前端传Token时习惯加上Bearer前缀比如Authorization: Bearer eyJxxx。如果后端判断逻辑没处理这个前缀就会导致登录状态一直校验失败。我统一在拦截器里做了replace(Bearer , )的兼容处理这算是一个典型的联调经验。4.2 图片上传方案本地存储与MinIO对象存储的取舍商品图片上传是这类平台的刚需。实现方案有两种主流选择我在文档里都写了。方案一是本地磁盘存储图片保存到服务器的某个目录通过Spring Boot的静态资源映射对外提供访问。配置非常简单spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB web: resources: static-locations: file:/home/project/upload/,classpath:/static/上传接口的核心逻辑是把MultipartFile写入目标目录然后返回可访问的URL。实测下来这个方案在单机部署、开发学习阶段完全够用缺点是图片不便于迁移和备份多机部署时图片不在同一台服务器上就没法访问。方案二是引入MinIO对象存储。MinIO是开源的对象存储服务兼容S3协议部署一个单机实例只需要下载一个二进制文件并运行。很多同学听到对象存储就觉得重其实以MinIO的体量配合spring-boot-starter-minio这类集成依赖代码量比本地存储多不了多少但换来的是图片管理的规范化桶、对象、访问策略都是标准对象存储语义以后迁移到云厂商的OSS、S3不需要改业务代码。标题热搜里也提到minio加入到springboot这确实是最近前后端分离项目里比较常见的需求。如果这个项目后续要扩展开源部署到多台服务器我会毫不犹豫换成MinIO方案。4.3 商品分页与多条件查询的实现商品列表页是整个系统访问量最大的接口核心要求是分页稳定、筛选条件可组合。我用MyBatis-Plus的分页插件实现条件组合通过LambdaQueryWrapper完成。public PageResultProductVO pageProducts(ProductQueryVO query) { PageProduct page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); // 关键字搜索标题模糊匹配 if (StringUtils.hasText(query.getKeyword())) { wrapper.like(Product::getTitle, query.getKeyword()); } // 分类筛选 if (query.getCategoryId() ! null) { wrapper.eq(Product::getCategoryId, query.getCategoryId()); } // 状态筛选前台默认只显示审核通过且在售的商品 wrapper.eq(Product::getStatus, 1); // 按创建时间倒序 wrapper.orderByDesc(Product::getCreateTime); PageProduct result productMapper.selectPage(page, wrapper); // 类型转换和补充发布者信息... }这里有一个性能相关的细节商品列表接口千万不要用selectList把全表数据查出来再在JVM里做分页数据量一大直接内存溢出。MyBatis-Plus的selectPage会生成带LIMIT的SQL分页在数据库层面完成这才是正确的姿势。另外查询条件里status1这个过滤条件必须加穷举的时候你会发现漏掉这个会导致已售出的商品还挂在列表里。5. Vue前端从搭建到交互路由守卫、Axios封装与页面复用5.1 前端工程化搭建与依赖安装要点前端工程我用Vite脚手架创建命令npm create vitelatest校园二手-front -- --template vue即可。项目创建后第一件事是安装核心依赖vue-router、pinia、axios、element-plus。Element Plus按需引入可以减少打包体积但我建议学习阶段的同学直接全量引入写起来省心等做性能优化时再考虑按需加载。这里聊聊vue安装及环境配置这块的经验。很多同学在配置Vue环境时反复出问题十有八九是Node版本和工具链不匹配。我在文档里给的参考环境是Node.js 18.16.0npm 9.5.1Vite 5.x。Node版本太低会导致Vite无法启动太高比如Node 21时偶尔会有依赖编译兼容报错。用nvm管理Node版本是IT圈比较省心的做法可随时切换版本。5.2 路由设计与登录守卫前端路由是整个页面导航的地图。校园二手平台的路由分成两部分前台页面首页、列表页、详情页、个人中心、发布页和后台管理页工作台、用户管理、商品审核等。我用Router把这两组路由直接写在同一个文件里通过meta.role字段标注访问需要的角色。登录守卫是前后端分离项目里前端安全的第一道防线。Vue Router的beforeEach钩子可以拦截所有路由跳转核心逻辑是如果目标页面需要登录但本地没有Token跳转到登录页如果目标页面需要管理员权限但本地用户信息里不是管理员跳转到首页并给出提示。router.beforeEach((to, from, next) { const token localStorage.getItem(token) const userInfo JSON.parse(localStorage.getItem(userInfo) || {}) if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }) } else if (to.meta.role to.meta.role ! userInfo.role) { next(/) } else { next() } })这里有个细节要提醒localStorage.getItem(token)返回的是null而不能转成布尔值很多同学在这里写if (localStorage.getItem(token) null)就漏掉了key存在但值为空的情况。用!token这种方式判断最稳。5.3 Axios封装与商品列表页交互Axios拦截器是前端处理接口一致性的关键手法。我在项目里封装了统一的request.js请求时自动附带Authorization请求头响应时统一处理code字段code为200就返回data数据为401就清空本地登录信息并跳转登录页其他错误码通过Element Plus的消息组件弹出后端返回的错误信息。这样一个封装写好所有页面的网络请求代码都能精简成非常干净的三行式调用。商品列表页是交互最复杂的页面我拆成了三个子组件SearchBar关键字和分类筛选、ProductList商品卡片网格、Pagination分页条。父组件维护状态子组件通过props接收数据、通过emit抛事件。搜索时点击搜索按钮触发父组件的loadData方法重新拉取第一页数据分页条翻页时触发pageChange事件用新的pageNum重新查询。完整交互链路跑通之后你会发现这类中后台页面做多了组件拆分的套路基本是一致的。商品发布页的表单校验也要提一下Element Plus的Form组件自带校验规则我在发布表单上配置了必填校验和价格字段自定义校验函数必须大于0的数字。图片上传组件使用el-upload配置action属性指向后端上传接口headers里带上Authorization才能通过后端的登录校验——这个header配置很容易漏漏掉的结果就是前端报401、图片死活传不上去。6. 前后端联调与部署跨域、打包、Tomcat/Nginx一次说清6.1 开发环境跨域问题的三种解法前后端分离的项目联调时第一个撞上的就是跨域问题。浏览器的同源策略规定当前端页面跑在http://localhost:5173后端接口跑在http://localhost:8080时两个端口不一致就被判定为跨域浏览器会拦截后端返回的响应。我在实践中有三种解法按推荐度排序第一种是后端开启CORS跨域配置。在Spring Boot里加一个配置类实现WebMvcConfigurer接口并重写addCorsMappings方法允许指定路径、指定来源访问。这个方案对前端开发环境固定的情况最简单几行代码解决。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(Registry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }第二种是前端Vite开发代理。在vite.config.js里配置server.proxy把/api路径的请求代理转发到8080端口。这个方案的优点是浏览器里看不到跨域代码也更干净。开发阶段推荐这种方式。第三种是Nginx反向代理这同时也是生产环境的标准方案放在6.3节详细说。6.2 前端打包与后端jar包部署的两种组合方式后端部署相对固定在项目根目录执行mvn clean packagetarget下生成一个可执行的jar包上传到服务器后执行java -jar target/校园二手-0.0.1-SNAPSHOT.jar服务默认跑在8080端口。需要注意的是一定要确认服务器防火墙放过8080端口或者用nginx把80端口转发到8080。前端部署有两种组合方式我分别验证过组合一Nginx部署前端 反向代理后端。前端执行npm run build后生成dist目录把这个目录上传到服务器配置Nginx的root指向distlocation /api/段配置proxy_pass转发到后端的8080端口。这是最标准的生产部署方式前端静态资源由Nginx高性能托管后端动态接口通过代理转发。Nginx核心配置server { listen 80; server_name campus-market.example.com; root /usr/share/nginx/campus-market/dist; index index.html; # 前端路由history模式支持 location / { try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }组合二把前端dist目录放到后端jar包里一起部署。Spring Boot支持把静态资源放在src/main/resources/static下前端构建后的dist内容复制到static目录重新打包后访问8080端口就能同时拿到前后端。适合小规模或演示场景缺点是不太利于前端独立更新。6.3 Tomcat部署与生产环境配置的注意事项标题热搜里有tomcat部署前后端分离项目这个需求在传统Java项目里很常见。虽然Spring Boot推荐直接用jar方式但有些学校机房或者公司基础设施要求部署到外部Tomcat环境。操作方法也不复杂把spring-boot-starter-tomcat的scope改为provided启动类继承SpringBootServletInitializer并重写configure方法最后打成war包放到Tomcat的webapps目录下。需要注意外部Tomcat和Spring Boot内置Tomcat的版本兼容性建议用Tomcat 9或10。有一点提醒外部Tomcat部署时前端dist依然放webapps的ROOT目录下接口请求要注意上下文路径。生产环境配置还有一个数据库时区问题需要提前处理。如果服务器默认时区是UTC数据库连接串里的serverTimezone不设置的话插入的时间会差8小时。我习惯把数据库连接URL统一加上serverTimezoneAsia/Shanghai同时在Spring Boot配置里指定jackson的时间格式前后端时间就能保持一致不会出现列表页显示的商品发布时间比实际慢了8小时这种诡异问题。7. 万字详设文档的价值与二次开发扩展方向7.1 详设文档包含哪些内容这套项目附带了一份万字详设文档很多人觉得写文档是凑字数、走形式但我自己的体会是一份完整的详设文档对二次开发和答辩演示的价值不亚于源码本身。文档里我按照软件开发的标准流程组织包含以下章节项目背景与可行性分析、需求分析含用例图与用例说明、系统功能结构设计、数据库详细设计含ER图、每张表的字段说明、接口设计文档每个接口的URL、参数、返回值示例、核心代码设计说明、系统测试报告、部署说明。以数据库设计部分为例文档不只是罗列字段还解释了每个字段的选取理由和潜在的业务扩展点。比如商品表里单独设计的degree字段如果以后要做筛选功能直接在列表查询条件里加上eq就可以不需要改表结构。这种设计和文档的结合让使用者拿到项目后不只是跑起来而是真正理解为什么这样设计。接口文档部分我做成了表格形式接口地址、请求方式、请求参数、返回参数、备注。以商品发布接口为例文档会标明POST /api/product/publish接口需要的参数title、description、price、categoryId、images、degree以及每种参数的类型和限制。前端照着这个文档联调半小时就能接完一个页面。7.2 基于源码的二次开发建议拿到源码之后我建议从这三个方向去做二次开发既容易出成果又能真正练到技术。第一接入校内统一身份认证。目前系统用的是用户名密码注册可以对接学校的统一身份认证平台OAuth2或CAS协议实现用学号直接登录。这个方向涉及OAuth2客户端配置、回调接口开发、用户信息映射技术含量适中做好之后切中校园场景的核心需求。第二引入在线支付。虽然面交是主流但支持在线支付可以覆盖部分不想带现金和转账的场景。比较推荐的接入方案是微信支付Native支付生成二维码或沙箱环境。重点要理解下单流程、回调验签、订单状态同步这三个环节支付回调的幂等性处理是关键中的关键回调丢失后的对账方案也要提前设计。第三增加消息通知模块。当前系统里买卖双方的联系主要靠订单信息比较被动。可以加一个简单的站内信或者系统公告推送用WebSocket做实时通知当有人收藏我的商品、我的商品被下单时推送给卖方。这个方向能把WebSocket、异步消息、前端实时通信练一遍在面试里也容易讲出亮点。7.3 几个容易踩的坑与我的实测经验最后分享几个我在开发和跑通这套系统过程中遇到的典型问题每个都是实测踩出来的。第一个坑是图片回显404。本地存储方案下图片保存到了服务器磁盘但Spring Boot默认不对外暴露file路径。新手最容易出现的错误是把图片URL写成localhost:8080/upload/xxx.jpg然后发现404。解决方式是在yaml里配置静态资源映射把upload目录映射到static-locations。第二个坑是BeanUtils.copyProperties导致的时间字段格式化丢失。在把PO转换成VO时直接用Spring的BeanUtils复制属性如果PO里的时间是LocalDateTime、VO里的时间是String复制时直接抛异常。处理办法是用Hutool的BeanUtil或者在VO里也保持LocalDateTime类型由全局Jackson配置统一格式化输出。第三个坑是前端打包后路由404。Vue Router默认是history模式打包部署到Nginx后直接访问某个子路由刷新会返回404。原因很简单Nginx找不到对应的静态文件。解决办法就是我在6.2节配置里的try_files $uri $uri/ /index.html把请求都引导到index.html由前端路由接管。第四个坑是数据库连接池失效。长时间运行后偶尔出现Connection is not available with timeout报错常见原因是MySQL的wait_timeout参数默认8小时连接池里的连接超过这个时间没被使用就会被服务端断开。解决办法是在连接串加上autoReconnecttrue或者使用HikariCP的keepalive-time配置。说回到这个项目本身校园二手交易平台看起来是一个常规的管理系统但它覆盖了用户认证、商品管理、订单流转、文件存储、前后端交互、部署运维这几个Java全栈开发者必备的技术环节麻雀虽小五脏俱全。我在实际整理这套代码和文档时的体会是真正把一个项目做到能交付、能部署、能讲解和只是能跑起来完全是两个层次前者需要你把每个模块的设计理由都想透彻。如果大家在复现或二次开发的过程中遇到了文档里没有覆盖到的问题欢迎在评论区留言交流。