先说一下最直接的感受基于SpringbootVue的房屋交易系统可能是这几个月被问得最多的一类题目。多数同学手里拿到的是一整套源码、部署文档、说明材料外加答疑服务但真正能一次跑通的很少。我最近完整整理过一套这样的房屋交易项目从业务模块到前后端代码从服务器部署到答辩文档算是一路踩坑过来的。这篇就把我从头到尾的整理思路写下来包括怎么理解业务、后端有哪些容易翻车的点、前端交互怎么接、数据库表怎么设计、部署时要注意什么以及最后写材料和演示的侧重点。想拿这个题目做毕业设计或者想用Spring BootVue练手的人可以把它当成一条比较完整的参考路径。这类系统的难点不在某个单独的技术点而在“交易流程”本身。房屋交易不是简单的信息展示它牵扯到发布、审核、浏览、收藏、预约、下单、状态变更等多个环节任何一个环节没想清楚后面写接口都要返工。所以我不建议一上来就建表写代码先把业务盘清楚再动手效率会高很多。1. 先盘业务房屋交易系统不只是一堆增删改查很多拿到题目的人第一反应是这不就是一个后台管理系统换个皮肤吗用户表、房源表、订单表做好再加几个页面就完事。实际做下来你会发现真正花时间的不是CRUD而是各种状态约束和角色权限。房屋交易系统的业务主线非常清晰房主发布房源管理员审核买家浏览、收藏、预约或下单最后完成交易。这条链路里每一步都有一套自己的规则这些规则直接决定表结构和接口设计。1.1 三个角色和“发布-审核-交易”的主链路先定义好角色后面权限和菜单都好处理。这个项目通常包含三类角色管理员平台运营方负责审核房源、管理用户、处理违规信息。放盘人也就是房主或房产经纪人登录后可以发布房源、修改房源、查看自己收到的预约和订单。买家/租客浏览房源列表查看详情收藏房源提交预约看房或交易订单。打个比方这就很像快递流程房主是寄件人管理员是安检员买家是收件人。房源就是那个包裹必须先通过安检才能进入运输环节。放到系统里安检就是后台审核运输就是前台展示和交易。一条完整的主流程可以这样走放盘人注册登录进入“我的房源”页面发布一套房子填写标题、描述、户型、面积、价格、地址再上传多张图片系统把房源状态置为待审核管理员在后台看到待审核列表点审核通过或驳回审核通过后前台房源列表才展示这套房买家浏览列表点击进入详情查看大图和完整介绍可以收藏也可以发起预约或购买订单订单状态再经历待确认、已确认、已完成或已取消的变化。这条链路只要走通项目的主干就算完成了。其余功能比如用户管理、公告、留言、个人信息修改都是在这个主干上长出来的枝叶。我给这套系统做模块拆分时就是按照这条链路来划分的后端Controller也基本一一对应房源发布、后台审核、前台查询、订单管理、收藏管理。1.2 容易被忽略的业务约束业务流程看起来简单但真正的工程量都藏在约束里。整理这套项目时我发现最容易出问题的点集中在下面几个地方。第一个是“审核通过才能展示”。房源表里如果只有一个“发布状态”那你就要额外判断是房主发布的都展示还是管理员审核通过的才展示我建议直接设计一个状态字段明确区分待审核、审核通过、已下架、已驳回。前台查询条件固定加上“状态等于审核通过”这样无论是列表还是详情页都不会把未审核的房源泄漏出去。第二个是“房源和订单的状态联动”。一套房子一旦被买家下单并且订单进入有效状态这套房源还能不能继续被其他人下单如果不做控制就会出现同一套房被两个人同时买走的尴尬情况。这里必须设计一个规则房源状态变为交易中之后前台就不能再发起新的订单。这个规则看起来简单实现的时候却最容易漏后面我会专门讲并发下的做法。第三个是“收藏与房源、用户的关联”。删除用户时收藏记录要不要一起删删除房源时收藏表里的脏数据怎么处理很多项目为了省事外键约束都不建结果后台数据越来越乱。我的建议是收藏表建立唯一的联合索引用户ID房源ID删除房源时顺手删除对应收藏记录接口里做完整一点。业务约束往往不会写在需求文档里是开发过程中慢慢浮出来的。我整理这套系统时先把上面这些规则写在笔记里再设计数据库后面写代码就少走了很多弯路。2. 后端Spring Boot房屋项目里最容易翻车的三个模块后端框架本身没什么好犹豫的Spring Boot 2.x配合MyBatis或MyBatis-Plus是毕设项目最常见的选择网上资料多自己封装也方便。真正容易翻车的不是框架搭建而是三个具体模块登录鉴权、房源审核的状态变更、下单时的并发控制。这三个模块我挨个说。2.1 登录态设计用JWT加拦截器就够了首先不要急着把Spring Security全家桶搬进来。Spring Security虽然强大但配置项多新手很容易配出一个“登录永远不过”的诡异状态。对于房屋交易系统这种规模的毕设一个JWT工具类加一个拦截器完全足够而且演示和答辩时你还能把原理讲得清清楚楚。JWT的核心逻辑很好理解用户登录成功后后端生成一个带过期时间的签名Token前端把Token存起来每次请求放到请求头里后端拦截器解析Token解析通过就放行解析失败就返回401。房屋交易系统虽然分了管理员和普通用户但Token里只需要存用户ID和角色需要判断权限时从解析结果里取角色即可。下面是一个比较典型的拦截器写法把Token解析出来的用户ID放进Request属性里后续Controller就能直接用。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、注册、前台房源列表等无需登录的接口 String uri request.getRequestURI(); if (uri.startsWith(/api/auth/login) || uri.startsWith(/api/auth/register) || uri.startsWith(/api/house/list) || uri.startsWith(/api/house/detail)) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); } try { Claims claims JwtUtil.parseToken(token); Integer userId Integer.parseInt(claims.get(userId).toString()); request.setAttribute(currentUserId, userId); return true; } catch (Exception e) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\登录状态已失效\}); return false; } } }写到这里要提醒一句拦截器注册的时候要把静态资源和上传文件的访问路径排除在外否则图片加载也会被拦。房屋交易系统里有大量房源图片如果拦截器把/upload/**路径拦了前台图片全挂。我当时就在这个细节上踩过坑排查了半天才发现是拦截器路径问题。另外就是跨域配置。前后端分离项目前端跑在8081端口后端跑在8080端口浏览器会拦截跨域请求。直接用WebMvcConfigurer配置全局跨域就行不用加CrossOrigin注解加得到处都是。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }2.2 房源状态流转审核接口要写成幂等操作房源审核是房屋交易系统里最有代表性的模块。房主发布房源后房源状态是“待审核”管理员点通过变成“展示中”点驳回变成“已驳回”展示中的房源可以手动下架变成“已下架”已驳回或者已下架的房子被修改后重新提交又回到“待审核”。这套状态流转中间有个很隐蔽的问题管理员如果连续点击两次通过按钮会不会把状态从“展示中”又更新一次代码层面看两次更新都执行成功看起来只是多更新一次没什么影响。但如果后面加了下架、交易中这些状态状态被重复覆盖就麻烦了。正确做法是给更新语句加上预期状态条件。也就是说更新前必须确认这条房源当前确实处于“待审核”才能更新为“展示中”。MyBatis里可以这样写SQLUPDATE house SET status #{targetStatus}, audit_time NOW() WHERE id #{houseId} AND status #{expectedStatus}Java代码里通过影响行数判断是否更新成功int rows houseMapper.updateStatus(houseId, targetStatus, expectedStatus); if (rows 0) { throw new BizException(房源状态已变化请刷新后重试); }这种写法有点类似乐观锁的思路不需要引入复杂的锁机制也能防止重复更新和并发状态下互相覆盖。审核驳回时我还会多存一个审核意见字段比如“图片不清晰”“地址信息不完整”前台和房主端都能看到这样体验更完整。2.3 订单模块并发不要以为毕设就不用考虑房屋交易系统和普通博客系统的最大区别就在于它有交易场景。两个买家同时看到同一套房几乎同时点了“立即购买”如果后端只是先查一遍房源状态再插入订单就很容易出现两个订单都插入成功。先查后插的问题在于两次查询都发生在状态改变之前都查到“展示中”随后都往下执行插入。要解决这个问题最直接的办法是把“判断状态”和“更新状态”合并成一条SQL利用数据库层面的行锁保证只有一个请求能更新成功。思路是这样下单时不再只是插订单而是先尝试把房源状态从“展示中”改成“交易中”UPDATE house SET status 交易中 WHERE id #{houseId} AND status 展示中如果影响行数等于1说明这个请求抢到了房源可以正常插入订单如果影响行数等于0说明这套房源已经被别人下单或者已经被下架直接提示用户“该房源已被预订或已下架”。这样一套组合拳下来不需要Redis分布式锁也能达到防超卖的效果。订单表本身也建议加上唯一约束比如同一个人不能对同一套房重复下单。可以用联合唯一索引house_id buyer_id is_active做一层兜底具体字段根据自己状态设计。接口设计方面我会统一返回一个Result对象格式类似{code, message, data}前端根据code判断成功失败。后端抛业务异常时使用全局异常处理器捕获并转成统一格式这样前端处理逻辑就很清爽不用每个接口自己判断乱七八糟的错误结构。3. 前端Vue实战页面怎么切数据怎么接前端用Vue 2或Vue 3都可以配合Element Plus或Element UI做后台界面开发速度很快。房屋交易系统的前端页面说多不多说少不少主要分为前台展示页面和后台管理页面两套前者偏C端风格后者偏管理系统风格。这里我不逐个页面讲只说几个容易被忽略但很影响使用体验的实现点。3.1 路由守卫、登录态和角色菜单房屋交易系统必须做登录控制。未登录用户能看房源列表、房源详情但不能收藏、不能下单管理员页面更是只有管理员角色能访问。最容易出问题的点是很多人把登录判断写死在每个页面里导致代码重复而且漏判断。建议统一在Vue Router里配置全局前置守卫每次路由跳转前都检查登录态和角色。Token存localStorage取的时候判断是否存在再结合路由meta里的角色信息做拦截。router.beforeEach((to, from, next) { const token localStorage.getItem(token) const role localStorage.getItem(role) if (to.meta.public) { next() return } if (!token) { next(/login) return } if (to.meta.roles !to.meta.roles.includes(role)) { next(/403) return } next() })菜单栏的渲染同样可以围绕角色来做。管理员看到的是“用户管理、房源审核、订单管理、数据统计”普通用户看到的是“我的房源、我的收藏、我的订单”放盘人看到“发布房源、我的房源”。最简单的方式是在菜单组件里根据role字段用v-if控制显隐不需要上复杂的动态路由。动态路由方案虽然看起来高级但权限逻辑和路由表写起来很容易乱毕设阶段不建议给自己加这个负担。3.2 房源发布表单与图片上传的链路全通房源发布页面是整个项目里交互最复杂的地方尤其图片上传。Element Plus的el-upload组件很好用但很多同学只把上传功能调通了图片回显却没有处理好结果发布完房源自己在详情页都看不到图。图片上传的完整链路是这样的前端通过el-upload把图片文件传到后端接口后端把文件保存到服务器磁盘某个目录同时把访问路径返回给前端前端把路径和房源信息一起提交浏览房源时后端返回图片路径前端拼上图片访问地址再渲染。el-upload上传时怎么带Token也是一个常见的卡点。一定要在请求头里加上Authorization字段el-upload :actionuploadUrl :headersuploadHeaders :on-successhandleUploadSuccess multiple list-typepicture-card i classel-icon-plus/i /el-uploaduploadHeaders() { return { Authorization: Bearer localStorage.getItem(token) } }后端接收上传文件时默认Spring Boot的单个文件大小限制是1MB。房源图片随便一张手机照片都是好几MB不修改配置的话上传一定会报错。所以要在application.yml里把上传大小调大一些spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB图片保存路径方面我习惯在服务器上单独建一个upload目录后端配置静态资源映射让/upload/**开头的请求直接访问磁盘目录。本地开发时如果路径配置失误最容易出的问题就是图片能上传成功但访问时永远404。这个坑我建议大家在代码里直接写清楚别用绝对路径写死到C盘D盘否则换一台电脑部署就全乱了。3.3 列表页的分页、筛选和交互细节房屋交易系统的前台房源列表是整个系统访问量最大的页面筛选条件通常包括户型、价格范围、面积、区域、关键词搜索还带分页。这批参数如果全传给后端后端统一拼SQL动态查询会比前端筛完再分页要稳定得多数据量大了也不怕。前端只需要做一件事维护好筛选表单数据然后把这些条件和分页参数一起发给后端。这里有个细节体验很关键搜索框输入的时候不要每次输入都立刻请求否则用户打字的过程中会触发大量无用请求。用防抖函数做个简单的300毫秒延迟用户停止输入后才发请求体验会顺滑很多。onSearchInput() { clearTimeout(this.timer) this.timer setTimeout(() { this.page 1 this.loadHouseList() }, 300) }列表页收藏按钮也有一个体验优化点用户点击收藏后接口返回成功前端只需要把当前卡片的数据局部更新成“已收藏”状态不要刷新整个列表。刷新列表会让用户感觉页面跳了一下而且会丢失当前滚动位置。房屋交易系统里房源列表卡片较多这种细节做到位演示效果会明显好于那些“点击按钮后页面闪一下”的项目。4. 数据库表设计真正拉开项目质量的部分数据库设计往往是答辩时老师问得最多的地方也是这套系统里最能体现思考深度的部分。很多房屋交易系统的代码本身写得中规中矩但表结构设计得合理接口写起来就顺手表结构设计乱后面所有代码都在填坑。4.1 核心表与字段说明我把这套系统的核心表定成以下六张每张表都有明确的职责边界表名用途关键字段user用户表存放管理员、放盘人、买家id, username, password, role, phone, create_timehouse房源表存放房屋基础信息id, user_id, title, description, price, area, address, cover_image, status, audit_reason, publish_timehouse_image房源图片表一个房源多张图片id, house_id, image_url, sorthouse_order订单表存放预约或交易订单id, house_id, buyer_id, seller_id, status, create_time, update_timefavorite收藏表id, user_id, house_id, create_timecategory房屋分类表如整租、合租、二手房id, name, sorthouse表是整个系统的核心字段设计要特别仔细。价格字段用decimal(10,2)不要用float否则可能出现0.1加0.2不等于0.3的问题面积字段用decimal(8,2)房源描述字段用text类型存放完整的文字介绍状态字段用tinyint就行配合一个枚举注释代码里定义一个常量类统一管理。4.2 字段类型与状态约定状态字段建议全部使用统一约定。我在这套项目里用的是房源状态0待审核、1展示中、2已下架、3已驳回、4交易中订单状态0待确认、1已确认、2已完成、3已取消、4已关闭。这些状态值写死在代码里太难看建议用一个枚举类或常量类统一管理。public class HouseStatus { public static final int PENDING 0; public static final int PUBLISHED 1; public static final int TAKEN_DOWN 2; public static final int REJECTED 3; public static final int DEALING 4; }逻辑删除是另一个容易踩坑的点。很多教程会建议每个表都加一个deleted字段防止用户误删数据。但我在房屋交易系统里不太推荐给house表加deleted字段因为房源状态本身就是最好的“逻辑删除”下架、驳回这些状态已经表示房源不可见了再加deleted反而让查询条件复杂化。只有favorite这类不重要的关联表删除了就删除了不需要软删除负担。数据库字段命名统一用下划线风格Java实体类用驼峰命名配置MyBatis的驼峰映射这样读代码时字段对应关系十分清楚不会像看天书一样。4.3 多图关联与查询陷阱房屋交易系统最常见的查询陷阱是图片字段的处理。很多新手图省事直接给house表加一个image_urls字段把多张图片路径用逗号拼接起来存进去。查询列表时确实方便但后续要单独修改某一张图片、筛选图片数量、统计图片数据时就会非常痛苦。而且用逗号拼接的方式一旦图片路径本身包含逗号或其他特殊字符解析就直接出问题。规范做法是设计单独的house_image表每条记录存一张图片通过house_id关联房源。查询时最忌讳的是遍历房源列表每套房都去查一次图片表这样列表有20套房就会产生20次图片查询也就是典型的N1问题。正确做法是先查出本页房源ID列表再一次性查这些ID的所有图片然后把图片按房源ID分组。MyBatis提供foreach功能或者MyBatis-Plus的in查询都很好实现ListHouseImage images houseImageMapper.selectList( new QueryWrapperHouseImage() .in(house_id, houseIds) .orderByAsc(sort) ); MapInteger, ListHouseImage imageMap images.stream() .collect(Collectors.groupingBy(HouseImage::getHouseId));把图片分组后再通过对象映射拼到每个房源的图片列表里。这个思路前后端都可以复用是房屋交易系统列表页性能优化的关键。5. 从开发到上线部署流程和故障处理系统开发完本地能跑只是第一步。毕业设计交的是要能让老师能打开看的东西所以一个清晰的部署文档很重要。很多同学源码写得不错但部署文档写得东一句西一句老师按文档操作根本跑不起来印象分会大打折扣。我整理这套系统时把部署流程归纳成了三步本地跑通、打包上传、服务器配置每一步都验证过。5.1 本地先把项目跑通后端环境需要JDK 1.8或11Maven 3.6以上MySQL 5.7或8.0。首先准备一个空的数据库然后执行项目里提供的SQL脚本把建表语句和初始数据导入进去。注意看SQL文件里是否包含数据库名如果没有需要先create database再执行。然后修改application.yml里的数据库连接配置这一步几乎80%的人会在这里卡住。密码是空的端口连不上都有可能出现。配置时要把时区写明否则MySQL 8.0会报时区错误spring: datasource: url: jdbc:mysql://localhost:3306/house_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password前端部分相对简单进入前端目录执行npm install安装依赖再执行npm run serve启动开发服务。前端项目一般会配置代理把/api开头的请求转发到后端8080端口这样开发时不用每次请求都写完整的后端地址。5.2 打包与服务器部署部署时后端用Maven打包成可执行jar包前端用npm run build把项目编译成静态文件。我通常把前端dist目录单独放到服务器的/opt/house/web下后端jar包放到/opt/house/server下上传图片保存到/opt/house/upload下这样三个目录职责清晰改起来也方便。后端的jar包用systemd管理比直接java -jar更可靠服务器重启后服务也能自动拉起。写一个简单的服务配置文件[Unit] DescriptionHouse Trading Server Afternetwork.target [Service] ExecStart/usr/bin/java -jar /opt/house/server/house-server.jar Restartalways RestartSec5 Userroot [Install] WantedBymulti-user.target配置好之后执行systemctl daemon-reload、systemctl enable house-server、systemctl start house-server就能通过systemctl管理后端服务了。前端静态文件需要Nginx来托管同时要把接口请求反向代理到后端8080端口。这是我的Nginx关键配置server { listen 80; server_name your_domain_or_ip; # 前端页面 location / { root /opt/house/web; index index.html; 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; } # 上传文件 location /upload/ { alias /opt/house/upload/; } }这里最容易被忽略的是try_files那行它是为了让Vue Router的history模式在刷新页面时不报404。少了这行你访问首页一切正常但刷新某个二级路由页面直接白屏这是前后端分离项目部署时的高频问题。5.3 部署后的常见故障排查部署完成后最好把日志打开遇到问题能快速定位。整理这套系统期间我遇到过几个高频故障这里整理成一张表按表排查效率很高现象原因解决办法前端刷新404Nginx缺少try_files配置在location /中添加try_files $uri $uri/ /index.html;图片能上传但访问404静态资源映射路径错误确认后端配置的upload目录与Nginx的alias路径一致接口返回401前端请求头没带Token检查请求拦截器是否在header中设置Authorization数据库连接失败MySQL白名单或密码错误检查云服务器安全组、MySQL账号密码、时区配置上传大图片失败multipart默认大小限制在application.yml中调整max-file-size和max-request-size接口请求超时服务器带宽或防火墙限制检查Nginx日志和systemd日志定位具体报错部署这种事经验都是在失败中积累的。我现在的习惯是每改一处配置就重启一遍服务并用curl测试一遍接口而不是全部改完再统一测试否则问题混在一起很难判断是哪个配置引起的。6. 交付文档和答辩源码之外的东西也要吃透项目能跑起来只解决了一半问题。毕业设计最终要交的是源码、论文、部署文档还要现场演示和回答问题。我也见过代码写得不错的人临场紧张连自己项目的表结构都说不清结果分数被拉低。所以这部分内容一定要认真对待。6.1 文档哪些部分必须自己重写很多同学拿到的文档模板是通用的里面的功能描述和自己的代码根本不是一回事。阅卷老师只要看出文档和代码对不上印象分就会大打折扣。整理这套系统时我建议重点检查以下几个部分。需求分析部分要写得具体角色的划分、业务流程的走向、功能模块的划分这些必须和代码一致。别再把“系统具有用户可操作性”这种废话写进去直接写“放盘人可以发布房源发布后房源进入待审核状态管理员审核通过后前台可见”这才是有效描述。数据库设计部分最容易暴矛盾。很多通用模板里的表名和你的表名不一致这种情况一旦被老师抽查几乎一查一个准。最好逐表核对每张表对应哪个功能模块关键字段的注释是什么表之间怎么关联都要过一遍。功能实现部分建议按模块写包括房屋发布、后台审核、前台检索、收藏、订单流程每个模块写清楚核心实现思路。不要贴一大段代码老师没时间看。用文字描述“使用了什么技术、解决了什么问题”反而更突出工作量。接口文档也要和代码严格对应。用Swagger或者简单的接口文档表格都行把请求方式、参数、返回值写清楚。如果答辩时老师随机问你某个接口的入参你却答不上来那场面会很尴尬。6.2 答辩演示的节奏与高频提问演示环节不要一上来就登录后台先讲需求。我的建议是按照真实业务顺序来演示既流畅又能体现项目思考。正规的演示顺序应该这样第一步注册一个“放盘人”账号登录后进入“发布房源”页面填写信息并上传几张图片提交发布。这一步展示房源从无到有的过程。第二步切换到管理员账号进入“房源审核”页面对刚才发布的房源进行审核通过后房源列表可见也可以演示驳回流程并填写审核意见。第三步切回前台以“买家”身份浏览房源使用筛选条件搜索房源进入详情页收藏提交下单。第四步回到个人中心查看订单状态变化。整个过程一气呵成比零散地点击菜单有说服力得多。答辩时被问到的高频问题也相对固定我这里列出几个常见的为什么用JWT而不是Session回答要点前后端分离架构下后端不保存登录状态扩展性好JWT自带过期时间适合分布式部署。Spring Boot比Spring MVC方便在哪回答要点自动配置、内置Tomcat、起步依赖减少版本冲突。为什么用前后端分离回答要点前端开发和后端开发可以并行前端打包后由Nginx托管后端专注提供接口。如何防止同一套房被重复下单回答要点利用数据库更新时的影响行数判断状态是否被抢占或者使用唯一索引兜底。房源图片怎么存储回答要点上传至服务器磁盘通过静态资源映射访问数据库只存路径这样迁移方便不会把图片存数据库导致性能下降。这些问题都不需要背答案关键是真正把自己代码看一遍根据代码逻辑回答。如果对某些部分不熟提前把核心代码打印出来或者多打开几个源码页面演示时随时能打开讲解会显得非常专业。6.3 二次开发和个人体会如果时间相对充裕我建议在基础上再加一两个亮点功能会让项目整体提升一个档次。比较推荐的方向有两个一是给房源列表和详情接口加Redis缓存热点房源查询不再频繁访问数据库这时候可以把“缓存穿透、缓存雪崩”作为答辩亮点二是在前台加入地图选房功能调用地图API获取经纬度房源列表用地图标记展示效果很直观。这两个改进都只需要改一小块模块但展示出来的工作量明显高于原版。如果让我重新整理一遍这套房屋交易系统我会在一开始就把状态枚举类和统一返回结果类定义好然后严格按照业务状态机写接口。这套系统真正花时间的不是代码量而是把状态流转和业务规则想清楚。只要业务链路梳理清晰Spring Boot加Vue的前后端分离写法几乎是水到渠成的事。最后说一个我自己很受用的小技巧不管拿到的是源码还是自己写的代码都要从头到尾运行一遍把每个按钮点一遍把异常情况都测一遍。把自己想象成老师拿着你写的部署文档从零操作哪里看不懂就改哪里。这样交付出去的源码和文档才不会有硬伤答辩的时候心里也踏实。