ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

SpringBoot+Vue+MyBatis校园闲置物品交易系统开发全流程详解

SpringBoot+Vue+MyBatis校园闲置物品交易系统开发全流程详解 1. 先说清楚校园闲置物品交易到底要解决什么问题每逢毕业季宿舍楼道里堆满了考研资料、小台灯、收纳箱甚至九成新的自行车。这些东西不是没人要是没人知道该去哪要——校园集市群的聊天记录翻几百条才能找到一个卖家二手平台发货运费比商品还贵线下摆摊又受时间和场地限制。做这个校园闲置物品交易系统本质上是把“闲鱼”的逻辑缩小到校园半径内同校学生之间完成发布、浏览、留言、交易把离校时恨不得扔掉的东西变成下届学弟学妹手里的宝贝。从项目层面看这是一个非常典型的Java全栈毕业设计/课程设计题目业务模型清晰但足够完整。它不要求你实现支付平台级的资金安全也不要求消息推送达到微信的并发量但它覆盖了从一个互联网产品想法到可运行系统所需的全部环节前后端分离架构、数据库设计、接口开发、权限验证、文件上传、部署运行。换句话说做完这一个项目你对“一个Web系统是怎么跑起来的”会有一个全景式的认知这比死记八股文有用得多。系统核心的角色只有三类普通用户买家和卖家的身份可以叠加、管理员、游客。游客可以浏览商品列表但要发布商品、留言、下单必须先注册登录管理员负责用户管理和商品审核。业务链条也是标准电商的简化版用户注册登录 → 发布闲置商品 → 其他用户浏览检索 → 感兴趣的话在线留言或直接下单 → 双方线下交易 → 商品标记下架。没有复杂的购物车和在线支付让整个系统的开发量控制在两三个星期内可完成同时又不失一个完整项目该有的技术覆盖度。我的建议是拿到这类题目不要直接开写代码先把业务边界画清楚。很多同学把系统设计得无比庞大又是积分、又是优惠券、又是多级分类最后光表就建了三十多张代码写了一万多行实际可用性反而不如一个功能收敛、逻辑自洽的小系统。校园闲置交易的核心只有商品、用户、订单三个实体其余都是围绕这三者转的辅助功能。2. 技术选型的理由为什么是SpringBoot Vue MyBatis MySQL 而不是别的这个标题里的技术栈几乎是目前Java Web开发的“标准套餐”SpringBoot做后端框架Vue做前端界面MyBatis做持久层MySQL存数据。有人会问为什么不直接用Spring Data JPA为什么不用Spring Cloud为什么前端不用React这些问题在答辩时老师大概率会问提前想清楚答案比背概念要好得多。2.1 后端为什么用SpringBoot而不是传统SSH/SSM早期做Java Web用的是SSHStruts Spring Hibernate或者SSMSpring SpringMVC MyBatis痛点在于配置地狱——XML配置文件动辄上百行环境搭建就能熬掉你两三天。SpringBoot的核心价值是“约定优于配置”内嵌了Tomcat一个main方法就能启动整个Web服务这对学生做项目来说是巨大的效率解放。具体到本项目SpringBoot带来的直接好处有三个。第一依赖管理简化引入spring-boot-starter-web就自动带上了SpringMVC和默认的Jackson序列化引入mybatis-spring-boot-starter就自动配好了SqlSessionFactory不用自己写一堆Bean。第二内置Tomcat本地调试不用再去下载安装一个独立Tomcat再配置server.xml。第三配置文件可以用application.yml统一管理数据库连接、端口、文件上传大小限制一目了然改配置不用重新编译。版本选择上需要注意这也是很多初学者踩坑的重灾区。如果用的是SpringBoot 2.7.x对应JDK 8或JDK 11都没问题如果没注意直接拉了SpringBoot 3.x就需要JDK 17以上且MyBatis对应的starter也要换版本很多旧教程的写法直接不能用。所以我的建议是不要盲目追求最新版本选SpringBoot 2.7.18这个终极2.x版本生态资料最丰富遇到问题搜解决方案最容易。2.2 前端为什么是Vue而不是原生JSP或者Thymeleaf传统方案里JSP和Thymeleaf都是服务端渲染页面逻辑和Java代码绑在一起前后端分不开。Vue的核心价值是实现了前后端分离前端工程独立开发调试通过Ajax请求调用后端的RESTful接口。这种模式更接近真实企业开发环境也是技术面试时被问得最多的能力。Vue在校园交易这个场景里最合适的点在于页面上有大量“状态变化”的需求。比如商品列表的排序筛选、搜索框的实时联想、收藏按钮的无刷新切换、下单弹窗的开关这些如果用JSP来做每次交互都要刷新整个页面或写大量原生JS操作DOM开发效率和体验都很差。Vue的响应式数据绑定让这些事情变得极其自然——数据变了页面自动变。前端构建工具建议使用Vue CLI对应Vue 2或者Vite对应Vue 3。考虑到网上教程的丰富度和毕设答辩文档的成熟度Vue 2 Element UI仍然是一个稳妥的选择写起来直观组件库颜值足够示例代码一搜一大把。如果你更想贴近当前企业用的主流技术Vue 3 Element Plus Vite也完全可行只是要注意和Node版本之间的兼容性。2.3 MyBatis和MySQL的组合逻辑MyBatis是半自动ORM框架SQL由你自己写但参数映射、结果集映射、动态SQL这些机械工作由框架代劳。选它不选Hibernate/JPA的核心原因是它的学习曲线平缓执行过程透明SQL调优方便。校园交易系统里有一个非常典型的业务——“根据多个可选条件筛选商品”——比如按价格区间、按商品分类、按成色新旧来组合查询。这种多条件动态查询用MyBatis的where和if标签做动态SQL每一个分支都直观可控。用JPA也不是不能做但自己拼Specification时对初学者来说抽象程度过高一旦排查问题就是一团乱麻。MySQL在这个项目里是最没有争议的选择。轻量、开源、安装方便、图形化管理工具成熟Navicat、SQLyog、DataGrip都行本地球的5万数据毫无压力。需要注意的只是安装时的字符集设置和时区配置这两个问题后面我单独说。3. 从0到1建库核心表结构设计与业务边界很多初学者建表喜欢把所有业务塞进一两张“万能表”里或者反过来把每个属性拆成单独的表。这两种都是极端错误。正确做法是先梳理业务活动中的名词再确定它们和动词之间的关系。3.1 数据表的总体设计本系统我建议设计六张核心表再加两张辅助表一共八张足够支撑整个业务而不显得臃肿表名核心字段用途说明t_userid, username, password, nickname, avatar, phone, role, create_time用户表role区分普通用户和管理员t_categoryid, name, sort商品分类表如书籍教材、电子产品、生活用品t_goodsid, user_id, category_id, title, description, price, original_price, degree, images, status, view_count, create_time商品表status表示在售/已下架/已售出t_orderid, order_no, goods_id, buyer_id, seller_id, price, status, create_time, finish_time订单表记录买家卖家关系和交易状态t_commentid, goods_id, user_id, content, create_time留言表潜在买家在商品下的留言t_favoriteid, user_id, goods_id, create_time收藏表t_noticeid, title, content, create_time公告表辅助表管理员发通知用t_admin_logid, admin_id, action, target, create_time操作日志表辅助表记录后台审核操作订单表为什么要同时存buyer_id和seller_id因为一个用户既可以是买家也可以是卖家订单本质上连接了“商品归属人seller”和“下单人buyer”。如果你只存一个user_id而试图在查询时反推卖家会给自己挖一个大坑尤其是在做“我买到的”和“我卖出的”这两个列表页面时你会发现查询逻辑绕得想哭。3.2 状态流设计与字典值约定业务里最核心的状态字段是goods.status和order.status。我强烈建议在编码前先把这两个字段的所有取值和流转关系用表格固定下来不要边写边想。商品状态我用的是三个值0 在售发布后默认状态1 已下架卖家主动下架或管理员审核下架2 已售出订单完成时自动置为该状态订单状态我用的是四个值0 待确认买家下单卖家未处理1 已确认卖家同意交易等待线下见面2 已完成交易完成商品状态同步改为已售出3 已取消买家或卖家取消订单这个设计是照抄成熟电商平台的状态机但做了大幅精简。为什么“待确认”和“已确认”要分开因为校园闲置交易场景下下单不代表成交卖家和买家往往需要沟通交易地点和时间。订单被确认后才意味着这笔交易正式进入线下履约阶段。状态机在代码里怎么落地最简单可靠的方案不是用状态模式而是把状态流转的控制逻辑写在一个Service方法里比如sellerConfirm(orderId, userId)方法内部先校验订单状态是否为0再校验当前操作者是否为seller都通过才把状态改为1。每个状态变化都做成一个独立方法比在Controller里随意set状态的写法安全得多。3.3 数据库初始化要注意的细节SQL脚本不要等到写代码的时候再临时建表我建议拿到题目后第一天就把建表SQL写好并执行到位。几个容易忽略的细节存储引擎统一InnoDB字符集统一utf8mb4注意不是utf8utf8mb4才能完整显示emoji和生僻字。主键一律用BIGINT AUTO_INCREMENT不要用UUID做主键。UUID作为主键在数据量小的时候没感觉但插入时索引页会产生随机IO后面数据量上来性能下降明显。统一给create_time字段加DEFAULT CURRENT_TIMESTAMP默认值这样插入数据时不用手动维护创建时间。价格字段用DECIMAL(10,2)不要用DOUBLE。DOUBLE存小数有精度丢失风险虽然学生项目里不会出大事故但这个习惯要从一开始就养成。索引方面除了主键索引必须给goods.user_id、goods.category_id、order.buyer_id、order.seller_id建立普通索引这几张表的核心查询条件都是这些字段。不加索引的表在数据量超过几千条后联表查询速度会肉眼可见地变慢。我还建议在初始化SQL里插入几条测试数据——几个不同分类的商品、两三个用户、一条留言。不要小看这件事后端接口写完后一启动前端页面立刻有数据可展示联调效率会提高很多而不是对着空白页面反复检查是不是接口写错了。4. 关键功能实现拆解登录、商品发布、订单流转中最容易翻车的几个点功能模块划分上我建议按用户端、商品端、订单端、管理端四个维度来组织代码。这一节不展开每一行代码但会把最容易翻车、最难排查的几个技术点讲透。4.1 登录鉴权JWT还是Session推荐选JWT前后端分离的架构下Session方案天然有跨域和浏览器Cookie策略的麻烦所以绝大多数现代项目直接用JWTJSON Web Token。流程是这样的用户登录成功后后端用密钥生成一个包含用户ID和过期时间的Token返回给前端前端把Token存在localStorage里之后每次请求在请求头里带上Authorization: Bearer token后端通过一个拦截器解析Token解析成功就放行并从Token里取出用户信息。具体实现上不推荐自己手写完整的JWT工具类直接用jjwt这个库引入依赖后大约二十行代码就能完成生成和解析。关键点在于密钥要写在配置文件里不要写死在代码中。Token过期时间建议设为24小时太短会导致用户频繁重新登录太长则有安全隐患。毕设项目24小时是一个平衡点。拦截器只做“登录校验”不写业务逻辑。放行白名单要配置好注册、登录、首页商品列表、商品详情这些接口游客也是可以访问的。我在实际写这类项目时还发现一个细节拦截器解析完Token后要把用户ID放到Request的attribute里Controller里再从request中拿而不是每个Controller都重新解析Token。这样统一处理后面写任何接口都可以直接用“当前登录用户”代码会整洁很多。4.2 商品发布与图片上传本地存储这么搞最省心学生项目不建议接入阿里云OSS理由很简单需要实名认证、需要配置Bucket权限、涉及跨域设置还要考虑流量费用成本虽低但流程繁琐容易在中途放弃。最本地的方案是“本地磁盘存储 后端映射为虚拟路径”。具体做法是在项目配置里定义一个上传根目录比如E:/project/upload/用户上传的图片按日期分子目录存放数据库里只保存相对路径比如/upload/2025/05/01/xxx.jpg。前端请求图片时URL写法是http://localhost:8080/upload/2025/05/01/xxx.jpg。为了让这个URL能访问到本地磁盘文件需要做一个静态资源映射配置本质上就是把/upload/**这个URL路径映射到本地磁盘目录上。这里有几个我踩过的坑必须强调配置文件里的上传目录如果写成相对路径在不同的启动方式下IDE启动、命令行启动、打包后启动指向的目录可能不一样。强烈建议写绝对路径或者用user.dir这个系统属性拼接相对路径但要在代码里做好目录不存在时自动创建的兜底逻辑。SpringBoot默认的上传文件大小限制是1MB但手机拍的照片动辄3-5MB所以必须在配置文件里把spring.servlet.multipart.max-file-size调大否则学生会反馈“图片传不上来”排查半天结果是框架限制。图片格式校验不能只依赖前端。后端拿到文件后要判断ContentType和扩展名是否匹配至少排除掉伪装成图片的可执行文件。4.3 订单流转的并发问题防止超卖是一种什么样的体验校园闲置交易里的商品只有一件所以不存在电商秒杀那种高并发超卖问题但依然有一个逻辑漏洞值得注意同一件商品被两个用户同时下单。这么说似乎很抽象举个例子你就明白了。用户A看中了那辆二手自行车点了“立即下单”还没付款前实际上我们的流程里没有在线支付下单即锁定意向其实商品应该是“被占用”状态不应再被其他用户下单。但如果代码没做状态校验用户B也能成功下单那卖家就要面对两个买家尴尬到脚趾抠地。解决这个问题的标准做法是在创建订单的Service方法里先执行一条UPDATE goods SET status 2 WHERE id ? AND user_id ! ? AND status 0形式的乐观更新这里的status2可以理解为“有单处理中”或者单独设计一个状态再通过受影响行数判断是否抢单成功。受影响行数为1表示更新成功商品被当前用户锁定为0则表示商品状态已变化被下架或已被别人锁定直接抛业务异常提示“手慢了宝贝已被他人锁定”。这种做法利用了数据库行锁的原子性代码也不复杂比先查询再判断再更新的方案安全得多。订单和商品的状态联动我也建议用同步事务实现即在同一个事务里同时更新订单状态和商品状态避免出现“订单已完成但商品还在售”的数据不一致情况。4.4 多条件筛选商品MyBatis动态SQL的典型应用商品列表页最常见的需求是按分类、价格区间、成色、关键词下拉筛选。用MyBatis写动态SQL是最舒服的场景核心逻辑是使用where标签配合if标签进行条件拼接。这玩意儿写起来不难但有个经典的坑——条件不生效。造成这个问题的原因通常有三个参数名没对上。Mapper接口方法里的参数如果没有加Param注解XML里用#{xxx}取值就取不到。判断条件写错了比如判断Integer类型的status时写成status ! 空字符串和Integer比较永远返回trueSQL就永远带上这个条件。XML文件没有刷新改了SQL但没重新编译运行的是旧class文件看起来“条件不生效”。这个功能还有一个体验上的加分项写SQL时使用ORDER BY和LIMIT配合实现分页但不要自己手动计算页码偏移。我建议直接引入PageHelper插件三行代码完成分页而且它和MyBatis的整合很成熟不用自己拼LIMIT减少出错面。5. 完整部署过程从MySQL安装到前端打包放进SpringBoot这一节是很多从来没独立部署过项目的同学的噩梦。IDE里能跑一部署就废问题是大概率出在环境一致性上。我把从零开始部署的整个过程完整梳理一遍照着做基本能一次跑通。5.1 MySQL安装的版本选择与安装陷阱先说版本。MySQL 5.7和8.0都可以用但我更推荐MySQL 5.7.44原因不是它先进而是教材和网上教程的大多数截图、配置项都基于5.7遇到问题最容易搜到答案。如果你一定要用8.0那么必须留意三个差异点不然会相当痛苦。8.0的默认认证插件是caching_sha2_password而很多老的数据库连接驱动包括一些老版本JDBC驱动不支持这个插件会导致连接报错Unable to load authentication plugin。解决办法是安装时选择Legacy Authentication如果用安装程序引导或者初始化后执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码。在SpringBoot的application.yml里连接数据库时5.7对应的驱动类是com.mysql.jdbc.Driver老版本驱动或com.mysql.cj.jdbc.Driver新版本驱动都兼容推荐后者8.0则必须用com.mysql.cj.jdbc.Driver且URL里必须要加serverTimezoneAsia/Shanghai否则会报时区错误。8.0连接串里还有一个容易忽略的项是useSSLfalse不关闭SSL的话控制台会打出一堆SSL警告不影响运行但看起来非常糟心。Windows安装时还有一个挂科级细节安装目录和数据目录不要有中文和空格。很多同学把MySQL装到C:\Program Files下后续读写数据文件时权限问题频出。建议装到D:/mysql这样的纯英文路径下。安装完成后用Root账号登录创建本项目专属的数据库和账号。千万不要直接用root账号连项目数据库虽然毕设项目没有安全审计要求但这个工作习惯值得养成CREATE DATABASE campus_trade DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER campuslocalhost IDENTIFIED BY your_password; GRANT ALL PRIVILEGES ON campus_trade.* TO campuslocalhost; FLUSH PRIVILEGES;5.2 SpringBoot后端的配置要点启动后端前把application.yml配置认真核对一遍这是我总结的常用配置模板server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_trade?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: campus password: your_password servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.campustrade.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: your-secret-key-change-me expire: 86400我单独解释一下map-underscore-to-camel-case这个配置。数据库字段风格是create_time、goods_id这种下划线命名Java实体类风格是createTime、goodsId这种驼峰命名。开启这个配置后MyBatis在把结果集映射为实体对象时会自动把create_time转成createTime不需要你给每个字段写resultMap。很多新手没开这个配置发现查询出来所有字段都是null排查几个小时其实一条配置就能解决。另外log-impl: StdOutImpl在开发阶段建议开启这样控制台会把每条SQL和执行参数打印出来排查MyBatis条件不生效的问题非常有帮助。上线前再把它注释掉即可。5.3 Vue前端构建与后端合并部署前端开发阶段用npm run serve跑在8081端口通过Vue CLI的代理配置解决跨域问题。在vue.config.js里配置module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这里建议前端所有请求都以/api开头后端Controller的RequestMapping统一加/api前缀。这样开发环境通过Vue代理转发到8080避免了开发时的跨域问题。但要注意代理只对开发环境有效。项目打包后前端文件是静态资源读取的是它所在服务器的接口地址此时根本没有代理服务器了。这时候有两个做法。第一个是部署时把前端打包产出的dist目录复制到SpringBoot项目的static目录下然后重新打包后端的jar包这样前端和后端同源都是8080端口不存在跨域。这个方案最适合毕设演示因为只需要在服务器上启动一个Java进程。第二个做法是用Nginx把前后端分开部署通过Nginx配置反向代理这种方案更接近企业级部署但需要额外安装Nginx、配置代理规则复杂度上去一个量级。我建议的项目演示方案是第一种前端打包后放进SpringBoot的static目录。具体操作是前端执行npm run build生成dist目录把dist目录下的所有文件复制到后端项目的src/main/resources/static下然后mvn clean package打出jar包java -jar启动。访问http://localhost:8080时默认首页就是Vue应用。这个方案有一个坑Vue Router在history模式下刷新页面时后端会去static目录里找路径对应的静态文件找不到就404。解决办法有两个要么把路由模式改成hash模式URL里会出现#号但简单可靠要么在后端加一个forward转发配置把所有非/api开头的请求转发到index.html。考虑到毕设项目对外观没有强烈要求我推荐直接用hash模式省心省力。5.4 打包部署时的Maven配置后端打包时有一个坑是SpringBoot的repackage插件。如果你用mvn package打包后发现生成的jar包只有几十KB而java -jar启动报“没有主清单属性”说明你用的是Maven默认的打包方式没有把SpringBoot的依赖打进去。必须在pom.xml的build节点里配置spring-boot-maven-plugin它会让最终jar包变成可执行的fat jar。如果你在IDEA里打包注意先执行mvn clean再mvn package避免旧编译产物残留导致新代码没生效出现的症状就是你改了代码但运行时行为没变化。6. 试跑过程中必须注意的坑跨域、MyBatis条件不生效、版本兼容这些这个项目我前前后后帮人调试过不下二十遍下面这些问题出现的频率可以说几乎每跑一遍都能踩中其中一两个。6.1 跨域问题开发环境和部署环境是两种解法开发模式下前端在8081后端在8080如果不做任何处理浏览器的同源策略会让所有Ajax请求失败控制台报错提示“CORS policy”。网上搜到的解决方案大多是后端加一个CrossOrigin注解或者写一个全局CorsFilter配置类。确实可行但我要提醒你这种方法只解决开发环境的问题而且会带来一个安全隐患它允许了所有来源的跨域请求allowedOrigins(*)对生产环境是不负责任的。更优雅的方案是前面说的Vue开发代理。它的原理是前端请求的是8081端口自己的地址Vue的devServer接收到请求后转发给8080对于浏览器来说请求来源和目标始终是同源的所以根本不会触发跨域拦截连后端都不需要写任何CORS配置。这个方案在开发和部署时都更干净。如果前端请求报404而不是跨域错误那大概率是你的代理路径拼错了。检查一下前端请求的URL是/api/goods/list还是http://localhost:8080/api/goods/list——用了代理后绝对不要写完整地址写了直接绕过代理必然跨域。6.2 MyBatis条件不生效的排查链路这个坑太经典了几乎每个用过MyBatis的人都遇到过。我给你一个完整的排查链路照这个顺序排查五分钟内能定位问题。首先打开控制台SQL日志配置里启用StdOutImpl。看打印出来的SQL语句里动态条件是否拼上了。如果SQL里压根没有WHERE条件说明XML里的if判断为false。此时分两步检查test表达式里的参数名是否正确XML里取的是#{title}Java方法参数就要有对应的Param(title)判断条件本身是否正确String类型判断! null and ! Integer类型只判断! null就足够了。如果SQL语句里条件拼上了但查询结果还是不符合预期那问题可能出在参数传递上。比如前端传的参数名是categoryId后端实体里的属性名却是category_id风格的映射不上导致参数是null。这种问题控制台SQL都能看出来——SQL里条件有了但绑定参数显示为null。还有一种情况是结果集映射问题。查询条件生效了返回的结果里某些字段是null。大概率就是前文说的没有开启map-underscore-to-camel-case或者实体类属性名和数据库字段名对不上。6.3 “SpringBoot版本太高”的连锁反应这个问题真的是2025年高频词。新手从网上下载一个开源项目模板SpringBoot是2.1.5这种老版本然后自己新建项目时IDEA默认拉取了3.3.x结果一大堆问题集中爆发JDK版本不对3.x要求17、javax包名全换成了jakarta、MyBatis的starter版本不兼容、老教程里的配置项全失效。这个局怎么破我给你的建议非常简单粗暴做毕设级项目别追求新版本锁定2.7.x版本线。它是2023年前最成熟的SpringBoot版本资料最多坑最少所有老教程的代码和配置基本通用。如果公司环境要求你用3.x那你得接受一套新规则但对于学习和毕业设计来说完全没有必要在版本兼容性上消耗宝贵精力。如果你非要挑战3.x记住关键的对应关系JDK使用17或21不能用8javax.servlet换成jakarta.servletMyBatis starter用mybatis-spring-boot-starter的3.0版本SpringBoot的配置项大部分没变但依赖传递的兼容性问题可能需要逐个排查6.4 文件上传后图片无法访问这个问题的表象是上传接口返回成功数据库里存了路径但前端图片URL打开是404。排查思路也很单一。先确认磁盘上文件是否真的存在——如果文件压根没上传成功检查配置里的上传大小限制是否被触发如果文件在但URL访问不到那就是静态资源映射没生效。检查你的映射配置路径和URL的前缀是否完全一致包括斜杠。比如你映射的是/upload/**URL写成/upload/xxx.jpg是对的但如果你映射的是/files/**URL却写成/upload/xxx.jpg那必然是404。另外一个隐蔽的问题是数据库里如果存的是完整地址http://localhost:8080/upload/xxx.jpg部署后域名或端口变了图片全挂。所以数据库里只存相对路径前端展示时动态拼接当前请求的域名和端口这是更健壮的做法。最后再分享两个实用的小技巧第一个是启动项目前先启动后端验证接口通不通再启动前端联调不要两边同时Sprint。怎么快速验证后端接口文档用Swagger集成SpringBoot 2.7对应springfox或springdoc或者简单的思路——后端启动后在浏览器直接访问http://localhost:8080/api/goods/list如果返回JSON数据说明数据库连接、Mapper、Controller都没有问题。再做UI是纯前端的事情错误面一下子缩小了一半。第二个是写代码时顺便把测试数据想清楚。我在建库时就在SQL脚本里塞好了5个用户、20件商品、若干留言和订单覆盖了“在售”“已下架”“已售出”三种状态、不同分类、不同价格区间。联调时无论是列表页的数据丰富度、筛选功能的测试还是订单流程的演示都能直接操作节省大量临时造数据的时间。另外把一套完整的账号信息写进README比如admin/123456、seller/123456、buyer/123456演示时用现成的账号不用现场注册答辩也会从容很多。做完这个项目你会发现校园闲置交易系统表面上是个两个星期就能写完的课程设计但认认真真走一遍从技术选型、建库、编码、联调到部署的完整流程之后你对Java Web开发的理解会有一个很大的提升。很多问题不亲手踩一遍看十篇文章都记不住。这个项目值得你亲手做一次。
返回列表