如果你正在做“SpringBoot Vue 旅游民宿预订管理系统”这类前后端分离项目这篇文章应该能帮你少走不少弯路。我会从项目选型、数据库设计、后端核心实现、前端工程化到部署上线按真实开发流程完整拆一遍所有代码和配置都是可以直接照着改的。1. 内容整体设计与思路拆解1.1 为什么选 SpringBoot Vue 这套组合旅游民宿预订管理系统这类项目本质上是典型的“信息管理 交易闭环”系统。用户端需要浏览民宿、查看详情、下单预订、支付、评价管理端需要维护房源、处理订单、管理用户、统计数据。前后端交互频繁、权限层级清晰、业务流程长选型时我优先考虑的是两点开发效率要够高技术栈要够主流。SpringBoot 在 Java 生态里几乎已经是 Web 项目的默认选择它解决了 Spring 框架配置繁琐的问题内置 Tomcat打一个 jar 包就能直接跑非常契合民宿这种中轻量级业务系统的后端需求。Vue 在前端生态里的地位也差不多组件化开发、响应式数据绑定、生态成熟配合 Element Plus 或 Ant Design Vue 这类组件库后台管理界面能很快搭起来。如果你问我为什么不选前后端不分离的传统模板渲染方案我的理由是民宿预订系统里用户端和后台管理端的 UI 差异非常大用户端注重浏览体验和移动端适配管理端注重表格、表单、图表的密集交互。前后端分离以后两端可以并行开发接口定义清楚就行后面再加小程序端或者 App 端直接复用同一套后端 API这是模板渲染方案很难做到的。1.2 功能模块拆解与业务边界划分在做需求分析的时候我习惯先把系统拆成“用户端”和“管理端”两个视角分别列功能再合并成模块这样业务边界更清晰。用户端核心功能注册登录手机号 验证码或用户名密码保存用户基本信息后续下单、评价都要依赖用户身份。民宿浏览按城市、入住日期、人数等条件搜索民宿列表页展示封面、标题、价格、评分详情页展示图片轮播、房型列表、设施服务、真实评价。预订下单选择入住日期和离店日期系统自动计算天数、总价提交订单后生成待支付订单。订单管理用户在个人中心查看订单列表、订单详情可取消未支付订单已入住后可发起评价。个人中心维护头像、昵称、手机号查看收藏列表查看评价记录。管理端核心功能民宿管理民宿基本信息维护名称、地址、城市、经纬度、描述、封面图每个民宿下面关联多个房型。房型管理房型名称、面积、可住人数、床型、价格、库存数量、房间照片。订单管理订单列表、订单状态流转待支付、已支付、已入住、已退房、已完成、已取消支持订单状态的人工干预。用户管理用户列表、账号状态正常/禁用必要时可查看用户的订单记录。评价管理评价列表、审核、隐藏违规评价。数据统计按日/月维度统计订单量、销售额、热门民宿排行用图表展示。我把模块关系用一句话概括就是用户产生订单订单关联民宿房型评价挂在订单下面。设计好这个关系后面写表结构就顺了。1.3 数据库表设计的几个关键点民宿预订系统的表结构不算复杂但有几个地方要特别注意我直接说核心的用户表sys_user字段包括 id、username、password、phone、avatar、role0普通用户 1管理员、status、create_time。密码必须加密存储实际项目里我用的 BCrypt不要用 MD5MD5 加盐也只是勉强能用BCrypt 是业界默认标准。民宿表homestayname、city、address、latitude、longitude、cover_image、images、description、facilities设施服务用 JSON 或逗号分隔字符串存储、status上架/下架、create_time、update_time。经纬度一定要存后面要做“附近民宿”或者地图展示会用到。房型表homestay_roomhomestay_id关联民宿、name、area、bed_type、max_people、price每晚价格、inventory库存、images。这里有个最常见的坑库存字段是 int 类型多人同时下单时如果直接inventory inventory - 1并发情况下会超卖。后面我会单独讲怎么用乐观锁解决。订单表orderorder_no订单编号、user_id、homestay_id、room_id、check_in_date、check_out_date、total_days、total_price、status、create_time、pay_time、cancel_time、check_in_time、check_out_time。订单编号用时间戳 随机数生成也可以引入雪花算法避免订单号重复。评价表commentorder_id、user_id、homestay_id、content、star_rating、images、status、create_time。这里注意评价一定要关联订单避免用户没下单就刷评价。表关系简单总结民宿 1 对多 房型用户 1 对多 订单订单 1 对 1 评价。外键我会在业务层维护数据库层面不强制物理外键而是用普通索引关联这样在做分表、扩展或者批量删除的时候更灵活。2. 核心细节解析与实操要点2.1 SpringBoot 工程搭建与版本选型的取舍我见过很多项目在版本选择上翻车SpringBoot 版本和 JDK 版本、与 Vue 的依赖版本不搭是非常常见的问题。以目前稳定度来说我推荐的组合是JDK 1.8 SpringBoot 2.7.x兼容性最好部署在普通服务器上没有任何压力。如果你的服务器和团队工具链已经比较新也可以用 JDK 17 SpringBoot 3.x但要注意 SpringBoot 3 是 Jakarta EE 规范javax 变成 jakarta很多老教程的代码不能直接照搬这可能是最容易踩的坑。这里展开说一下SpringBoot 3.x 里最直观的变化是javax.servlet变成了jakarta.servlet连接池、MyBatis、Druid 这些中间件的适配版本也全部变了。如果你还在用网上搜到的大量 SpringBoot 2.x 的教程代码直接复制到 3.x 项目里会报一堆包不存在的错误。所以我的建议是如果你对这套技术栈还不熟直接用 SpringBoot 2.7.x 起步网上资料多、遇到的坑少、面试时对方也更熟悉如果团队有精力踩新版本的坑再考虑升级。后端核心依赖清单是这样的dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency /dependenciesMyBatis-Plus 我强烈建议用它对单表 CRUD 做了极强的封装基础增删改查不用写 SQL项目早期进度会快很多。不过如果是多表关联查询还是要自己写 XML SQL。2.2 后端分层架构与统一响应规范工程结构我用的是最常见的四层结构Controller → Service → Mapper另外还有一个 entity / dto / vo 的区分。很多新手在前后端联调时最头疼的就是接口返回的字段一会儿是 null一会儿字段名对不上根源就在没有做数据对象隔离。我的划分标准是这样的Entity数据库表直接映射的对象字段与表字段完全一致。DTOData Transfer Object接收前端传入的参数比如下单时前端传 userId、roomId、checkInDate、checkOutDate后端用 DTO 接收不直接用 Entity 接收。VOView Object返回给前端的数据对象比如订单详情里需要展示民宿名称、封面图这些字段在 order 表里没有需要组装进 VO。统一响应体我定义了Result类Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }这样做的好处是前端 axios 拦截器里只需要统一判断res.code 200然后取res.data不用每个接口都写一遍错误分支。权限验证我用的是 JWT。用户登录成功后后端生成一个 token 返回给前端前端把 token 存到 localStorage 或 pinia之后每次请求在 axios 请求拦截器里加上Authorization: Bearer ${token}后端定义一个拦截器解析 token校验通过才放行。2.3 订单并发与库存扣减的实现思路这是民宿预订系统里技术含量最高的一块如果你把这个问题处理好了简历上、面试里都有得聊。先还原一下问题场景一个热门民宿的某一晚只有 3 间房同时来了 5 个人下单如果你用最简单的“查库存 → 判断库存 0 → 扣库存 → 生成订单”这种流程5 个请求同时执行的时候可能每个请求都查到了库存为 3于是都通过了判断最后库存可能变成 -2这就是经典的超卖问题。解决方案有很多我说两种适合这个项目的。第一种乐观锁。在房型表加一个 version 字段更新库存的时候用带条件更新的 SQLUPDATE homestay_room SET inventory inventory - 1, version version 1 WHERE id #{roomId} AND version #{oldVersion} AND inventory 0受影响行数为 0 说明版本号不匹配或库存不足此时直接返回“该房型已被抢完”让用户重新选择日期。这种方案实现简单适合并发量不高的民宿预订系统。第二种使用 Redis 分布式锁。在扣库存前先获取锁String lockKey room:lock: roomId; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(系统繁忙请重试); } try { // 执行库存查询 扣减 生成订单 } finally { redisTemplate.delete(lockKey); }注意 set 操作一定要设置过期时间防止线程拿到锁后崩溃锁永远不释放造成死锁。这里的过期时间一般设置成业务执行时间的 2~3 倍。除库存外还有一个业务逻辑要处理好订单超时未支付自动取消。用户下单后 30 分钟内没付款订单状态要变为已取消把库存释放回去。最简单的实现是定时任务每分钟扫描一次订单表把超时未支付的订单取消并恢复库存。更高阶一点的方案是用 RabbitMQ 延时队列但民宿项目里定时任务完全够用别过度设计。2.4 文件上传、静态资源映射与接口安全民宿的封面图、房间图片、用户的头像都涉及文件上传。这类功能有两个方案一个是把图片传到云存储对象存储另一个是传到本地服务器磁盘。考虑到项目要能本地运行、方便展示我文章里用的是本地存储方案并做了静态资源映射。上传接口的控制器核心代码PostMapping(/upload) public ResultString upload(RequestParam(file) MultipartFile file) { // 检查文件大小我限制在 5MB 以内 if (file.getSize() 5 * 1024 * 1024) { return Result.error(500, 文件不能超过5MB); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); // 生成唯一文件名避免文件名冲突 String fileName UUID.randomUUID().toString().replace(-, ) ext; String datePath LocalDate.now().format(DateTimeFormatter.ofPattern(yyyy/MM/dd)); File dir new File(uploadPath datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath() / fileName)); return Result.success(/upload/ datePath / fileName); }然后把上传目录映射成静态资源路径。在 SpringBoot 里加一个配置类实现 WebMvcConfigurerConfiguration public class WebMvcConfig implements WebMvcConfigurer { Value(${upload.path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }这样前端拿到/upload/2024/01/01/xxx.jpg这个 URL 就能直接访问图片了。接口安全方面除了 JWT 拦截器管理端的接口还要做角色校验。我再补充一个容易被忽略的点如果项目里涉及到对接第三方 API比如对接携程的库存同步、对接支付网关通常需要 API Key 签名机制。做法是调用方生成一个时间戳 随机 nonce 请求参数拼接用双方约定好的密钥做 HMAC-SHA256 签名服务端用同样的规则重新算一遍签名相等才放行同时时间戳和 nonce 用于防止重放攻击。这个机制放在民宿项目里可以作为加分项面试时提一下很加分。3. 实操过程与核心环节实现3.1 Vue 工程初始化与目录结构规划前端我推荐 Vue 3 Vite。Vue 3 已经是绝对的主流Vite 开发体验比 Webpack 好太多启动速度快HMR 也快。如果你所在的公司还在用 Vue 2 Webpack多半是存量老项目新项目直接上 Vue 3 不用犹豫。环境准备方面先装 Node.js。这里强调一下不推荐直接去官网下载最新版 Node也不推荐装一个就用到天荒地老。Node 版本管理工具 nvm 是必须的因为不同的 Vue 项目可能依赖不同版本的 Node。比如老项目用 Node 14新项目用 Node 18没有 nvm 的话来回切换会很痛苦。我用的实际步骤如下# 安装 nvm 之后 nvm install 18.18.0 nvm use 18.18.0 node -v # 使用 Vite 创建 Vue3 项目 npm create vitelatest homestay-frontend # 选择 Vue 模板 cd homestay-frontend npm install npm run dev创建好之后目录结构我会做一次大调整形成一套适合业务开发的推荐结构src/ ├── api/ # 接口请求封装按模块拆分 │ ├── request.js # axios 实例拦截器 │ ├── homestay.js # 民宿相关接口 │ └── order.js # 订单相关接口 ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── router/ # 路由配置 ├── stores/ # Pinia 状态管理 ├── views/ │ ├── home/ # 用户端页面 │ ├── homestay/ │ ├── order/ │ └── admin/ # 管理端页面 ├── utils/ # 工具函数 ├── App.vue └── main.js一个核心原则每个模块的文件都放在自己的目录里不要把所有组件全部丢到 components 下否则项目规模变大后找文件会崩溃。3.2 路由配置与历史模式部署避坑Vue Router 4 的配置方式如下import { createRouter, createWebHistory } from vue-router const routes [ { path: /, component: () import(../views/home/index.vue) }, { path: /homestay/:id, component: () import(../views/homestay/detail.vue) }, { path: /login, component: () import(../views/login.vue) }, { path: /admin, component: () import(../views/admin/layout.vue), meta: { requiresAuth: true, role: admin }, children: [ { path: homestay, component: () import(../views/admin/homestay.vue) }, { path: order, component: () import(../views/admin/order.vue) } ] } ] const router createRouter({ history: createWebHistory(), routes }) // 全局前置守卫 router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } })有一处很关键createWebHistory 是 HTML5 History 模式URL 里没有#好看但刷新页面时如果 Web 服务器没做重写就会直接返回 404。开发环境下 Vite 帮你处理了生产环境部署到 Nginx 时必须在 Nginx 配置里加try_files $uri $uri/ /index.html;这行配置的意思是不管请求什么路径都先找对应的文件找不到就回退到 index.html由 Vue Router 自己来匹配路由。这个问题我在部署时踩过好几次后面前后端联调那节会再提一次。3.3 核心页面与交互逻辑实现民宿列表页要展示一堆卡片信息写起来不复杂但要注意状态管理与数据传输的细节。列表页的筛选条件城市、日期、人数、关键字用 Pinia 存起来因为用户在列表页设置条件后点击进入详情页再返回列表页时筛选条件要能保留。类似这种跨页面的状态放在 pinia 里比每个页面自己维护要合适得多。详情页是系统的核心页面要展示民宿图片轮播、房型列表、日期选择、评价列表。日期选择和价格计算是关键交互用户选择了入住日期和离店日期之后要实时计算总价 每晚价格 × 天数。这里我用 computed 来实现实时计算。Vue 里 computed 和 watch 是初学者经常混淆的我说一个最直白的理解方式当数据 A 变化时需要计算出新数据 B 展示在页面上用 computed当数据 A 变化时需要执行一段副作用逻辑比如发请求、写日志用 watch。计算订单总价就是典型的 computed因为它是 pure function只依赖输入数据。script setup import { ref, computed } from vue const checkInDate ref() const checkOutDate ref() const price ref(368) const totalDays computed(() { if (!checkInDate.value || !checkOutDate.value) return 0 const start new Date(checkInDate.value) const end new Date(checkOutDate.value) return Math.ceil((end - start) / (1000 * 60 * 60 * 24)) }) const totalPrice computed(() { return totalDays.value * price.value }) /script注意totalDays最大值要限制一下我在实际项目里加了一个校验离店日期不能早于入住日期连续预订天数不能超过 30 天这些校验放在前端和后端各做一遍前端为了用户体验后端的才是真正安全的。民宿详情页还有一个常见需求是展示实拍视频有些民宿会有视频介绍。这里就涉及到一个前端问题视频编码格式是 H.265 的 m3u8 流媒体格式时普通的video标签是播放不了的。这块我的处理方案是使用 hls.jsimport Hls from hls.js function playM3u8(videoElement, src) { if (Hls.isSupported()) { const hls new Hls() hls.loadSource(src) hls.attachMedia(videoElement) } else if (videoElement.canPlayType(application/vnd.apple.mpegurl)) { // Safari 原生支持 m3u8直接赋值即可 videoElement.src src } }如果是直接把 m3u8 当作项目里的一个技术点面试的时候能讲清楚 HLS 协议的基本原理和 hls.js 的工作方式会是一个不错的加分项。3.4 前后端接口联调的关键配置前后端分离开发时本地联调最大的问题是跨域。开发环境下我推荐用 Vite 的代理配置而不是在后端直接加 CORS 配置。原因是后端加了 CORS 之后生产环境如果前端和后端部署在不同域名下仍然要处理跨域后端把跨域放开意味着任何来源都能调用接口安全性差一些。Vite 的 proxy 配置放在vite.config.jsimport { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ) } } } })这样前端代码里所有请求都写成/api/homestay/list开发时 Vite 帮我们转发到后端的http://localhost:8080/homestay/list代理转发是服务端的请求不存在跨域问题。而后端接口只允许同源访问安全面更小。生产环境部署时前端静态文件交给 Nginx后端 SpringBoot 跑在 8080 端口前端请求/api时由 Nginx 反代到后端服务location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }这里有个小细节proxy_pass http://127.0.0.1:8080/;后面带了/意味着去掉了/api前缀。如果想让后端接口保持/api/homestay/list这种路径就把 proxy_pass 改为http://127.0.0.1:8080;不带路径。两种方式都行但是前后端要对齐不然就会 404。4. 部署上线与常见问题排查实录4.1 SpringBoot 后端打包与 Docker 部署本地开发用 IDE 直接运行部署到服务器我推荐用 Docker。用 Docker 部署 SpringBoot 项目的常规做法是先用 Maven 把项目打成 jar 包然后写 Dockerfile 构建镜像。一个基础可用的 DockerfileFROM openjdk:8-jdk-alpine WORKDIR /app COPY target/homestay-backend.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]构建和运行命令mvn clean package -DskipTests docker build -t homestay-backend:1.0 . docker run -d \ --name homestay-backend \ -p 8080:8080 \ -v /data/upload:/data/upload \ -e SPRING_PROFILES_ACTIVEprod \ homestay-backend:1.0有几个点必须提醒上传的图片文件放在容器内部的话容器重新构建后数据就丢了所以宿主机目录/data/upload一定要挂载到容器里保证文件持久化。数据库连接信息、Redis 密码等敏感配置不要写死在 application.yml 里通过-e环境变量或外部配置文件注入。SpringBoot 的环境变量配置优先级比 jar 包里的配置文件高所以可以放心覆盖。如果你在本地电脑用 Docker Desktop还有一个常见问题Windows 上挂了目录后容器内文件权限可能不对导致文件上传失败。遇到这种情况先docker logs看容器日志基本就是目录权限问题chmod 一下宿主机目录即可。4.2 Nginx 配置生产环境前端前端构建npm run build构建完成后 dist 目录传到服务器Nginx 配置server { listen 80; server_name your-domain.com; root /data/www/homestay-frontend; index index.html; 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /upload/ { alias /data/upload/; } gzip on; gzip_types text/plain text/css application/json application/javascript; }location /upload/那一段是给上传的图片做访问映射的不配置的话前端页面上的图片全部加载不出来。gzip 是压缩静态资源的开启之后页面首屏加载速度会有明显提升顺手就做。4.3 常见问题速查表我在做这个项目的过程中遇到过不少问题整理成一个速查表直接对应排查步骤问题现象可能原因解决方案前端请求接口返回 404Vite 代理未生效或 Nginx 的 try_files 缺少检查 proxy 配置生产环境确认 location /api/ 已配置刷新页面 404前端使用 history 路由但服务器没配置 rewriteNginx 加 try_files $uri $uri/ /index.html;上传图片后访问 404静态资源映射未配置或映射路径不对检查 WebMvcConfig 的 addResourceLocations确认目录存在登录后接口返回 401token 过期或请求头未携带 token检查 axios 拦截器确认 Authorization 拼接正确同时下单库存变负数没有加乐观锁或锁失效用 UPDATE 带 version 条件扣库存或加 Redis 锁本地能跑部署后启动失败配置文件环境变量覆盖导致数据库地址不对docker logs 看日志确认数据库地址和密码是否正确SpringBoot 3.x 项目启动报错依赖版本不适配检查 jakarta 包替换、MyBatis 适配版本Vue 页面白屏构建后的 js 报错或资源路径不对浏览器 F12 看 Console确认根路径资源加载情况4.4 关于 SpringBoot 自动装配和循环依赖我踩过的坑SpringBoot 项目做久了你一定会遇到“循环依赖”这个老大难问题。举例说明订单服务OrderService需要调用用户服务UserService获取用户信息然后因为业务调整用户服务的方法里又需要调用订单服务查询用户的订房记录这就形成了 A 依赖 B、B 依赖 A 的循环。Spring 解决循环依赖依赖的是三级缓存机制singletonObjects、earlySingletonObjects、singletonFactories。SpringBoot 2.6 版本之前默认允许循环依赖但从 2.6 版本开始官方把循环依赖处理默认改为禁止项目启动时直接报错“The dependencies of some of the beans in the application context form a cycle”。我建议的解决方案是重构代码让依赖方向更清晰把订单相关的查询逻辑抽到一个独立的 OrderQueryService 里UserService 只需要调用 OrderQueryService不直接依赖 OrderService这样从设计上消除循环。如果只是想快速解决启动报错可以在 application.yml 里加spring.main.allow-circular-referencestrue不推荐这是治标不治本。另外很多人在面试会被问“SpringBoot 自动装配原理是什么”放在这个项目里也很好回答SpringBoot 的SpringBootApplication注解里包含EnableAutoConfiguration它通过AutoConfigurationImportSelector加载META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里声明的一堆自动配置类这些自动配置类里用大量的ConditionalOnClass、ConditionalOnMissingBean条件注解做到“你引入了某个依赖它就自动帮你配置好对应的 Bean不需要手动写配置类”。理解了这个原理你在项目里写自定义 starter 或者调试连接池配置的时候会清楚地知道应该在哪里动手。5. 一些小技巧和扩展建议这个项目做完之后往上扩展的方向其实不少我按难度从低到高排一下民宿详情页接入地图功能我用的是腾讯地图 JavaScript API通过经纬度标记民宿位置顺便把附近的景点、餐饮也标上去。Vue 里集成腾讯地图的方式很简单去控制台申请一个 key然后在 index.html 里引入 script或者在组件的 onMounted 里动态创建 script 标签加载避免在首页就加载一堆用不到的资源。民宿视频播放可以升级成配套的视频转码服务用 FFmpeg 把用户上传的 mp4 转成 m3u8 切片配合 hls.js 方案实现流媒体播放体验会好很多。支付模块可以对接微信支付或支付宝沙箱环境民宿项目的核心交易闭环里加上支付状态回调在回调里做幂等处理会让整个系统的订单状态流转真正完整。使用定时任务配合 Redis 做热门民宿的缓存统计降低数据库压力。民宿列表页的搜索热度比较高的城市可以先把数据缓存到 Redis设置合理的过期时间比每次查数据库快很多。前后端接口文档用 Apifox 统一管理接口定义好后自动生成文档前端可以直接模拟接口数据不等后端写完就能并行开发。最后分享一个我个人的习惯开发前先把表结构和核心接口文档确定下来再分头开发。民宿项目的需求相对清晰做正向后端接口先定下来前端连 Mock 数据开发差不多两天时间前后端就能进入联调整体效率比边写边沟通高出很多。实际做下来这个项目用的技术点非常经典SpringBoot、Vue、MySQL、Redis、Nginx 都是当前就业市场的主流技能把这个闭环跑通比单纯刷教程学的深入得多。如果你正在写相关项目希望这篇文章能帮你省下一些时间。