基于Vue+SpringBoot的民宿旅游管理系统设计与实现

带过不少计算机专业的毕业设计也帮人排查过各种奇奇怪怪的系统问题但每次看到民宿旅游管理系统这种题目还是觉得挺有意思。原因很简单这题目看似常规实际上把前后端分离、权限管理、订单状态机、文件上传、支付回调这些真实业务场景全塞进来了做好了完全可以直接拿去找工作当项目经验讲。今天我把自己做这套基于 Vue SpringBoot 的民宿服务一体化系统的完整思路、核心代码、踩坑记录都整理出来打算做毕设或者想练手 SpringBoot 全家桶的朋友可以直接照着折腾。先交代一下这系统是干嘛的前台面向游客支持民宿房源检索、房型浏览、在线预订、订单支付、个人中心后台面向管理员和房东支持房源管理、订单管理、用户管理、数据统计。整体采用目前主流的前后端分离架构前端 Vue 负责页面交互后端 SpringBoot 提供 RESTful API数据库用的 MySQL权限用 JWT Spring Security 控制。这套组合在毕设里属于稳中带秀的类型既不会因为技术太偏导致答辩老师看不懂又有足够的业务复杂度体现工作量。1. 整体设计与技术选型思路1.1 为什么选 Vue SpringBoot 而不是其他组合毕设选技术栈第一原则是自己看得懂老师也看得懂。Vue SpringBoot 在国内Java方向的项目里几乎是默认答案学习资料多、社区活跃、遇到问题搜一圈就有答案。比起 SSM 时代那种手动拼 JSP 页面的做法前后端分离能让项目结构更清晰前端管展示、后端管业务两边各自独立开发、独立部署。SpringBoot 相比传统 Spring MVC 最大的好处是自动配置和起步依赖。你不需要再写一堆 XML 配置文件一个spring-boot-starter-web就把内嵌 Tomcat、Jackson、参数校验都带进来了。对毕设来说这意味着可以把时间花在业务实现上而不是纠结配置文件写错导致启动失败。Vue 这边我用的是 Vue 2 Element UI 的组合原因比较现实Element UI 的中文文档完善表格、表单、分页、对话框这些后台管理常用的组件都有现成的前端页面做出来不会太丑答辩演示的时候视觉分能拿到手。1.2 功能模块划分的思考拿到题目先别急着写代码把需求拆清楚才是关键。民宿旅游管理系统核心是民宿和旅游所以业务上要覆盖以下几条线游客线注册登录 - 浏览房源 - 查看房型与价格 - 提交预订 - 在线支付 - 入住 - 退房 - 评价。房东线申请成为房东 - 发布房源 - 管理房态 - 处理订单 - 查看收益。管理员线审核房源 - 管理用户 - 处理投诉 - 运营统计。三条线在前台和后台各有入口对应前端两套界面。用路由做区分即可前端项目里设置/admin前缀的路由统一走后台布局普通路径走前台官网布局。后端接口则用权限注解区分角色比如PreAuthorize(hasRole(ADMIN))只允许管理员访问。1.3 数据库设计的核心权衡数据库表我主要围绕这几个核心实体设计用户表、民宿表、房型表、订单表、评价表、收藏表、公告表。其中订单表是整个系统的核心字段设计直接关系到后续开发顺不顺。订单表一定要包含订单编号、下单用户ID、民宿ID、房型ID、入住日期、退房日期、房间数量、总金额、订单状态、创建时间、支付时间。关于状态字段我用的是Integer类型而不是字符串0待付款、1已付款/待入住、2已入住、3已退房/已完成、4已取消、5已退款。用数字的好处是后端比较状态和前端映射文案都很方便比如前端读取到 0 就显示待付款按钮可以设为去支付。价格计算这里有个容易忽略的点民宿的价格分平日价和节假日价也就是一个房型有price和holidayPrice两个字段。计算订单总价的时候先判断入住日期区间内是否包含节假日再逐天累加价格再乘以房间数量。这个逻辑看起来简单但很多人在第一次做的时候随便拿price * days就算了结果后续答辩被老师一问节假日涨价怎么处理就答不上来。2. 技术栈选型与系统架构拆解2.1 后端分层架构后端项目我按常见的四层结构组织Controller 层负责接收请求和参数校验Service 层处理业务逻辑Mapper 层Dao层操作数据库Entity 层承载数据对象。有人觉得这么做麻烦但毕设项目里这种清晰分层反而是加分项答辩时老师问项目怎么组织的你直接按这个结构讲逻辑非常顺畅。具体包结构建议这样设计com.example.homestay ├── controller # 前端控制器 ├── service # 业务接口 │ └── impl # 业务实现 ├── mapper # MyBatis接口 ├── entity # 数据库实体类 ├── dto # 前端传输对象 ├── vo # 视图对象 ├── config # 配置类 ├── utils # 工具类 ├── common # 通用返回结果、异常处理 └── interceptor # 拦截器这里重点说一下 VO 和 Entity 分离的问题。很多人做项目图省事直接把数据库实体类返回给前端这个习惯很不好。比如用户表里有密码字段你直接返回 Entity 就等于把密码哈希也发给前端了。正确做法是定义一个UserVO只包含用户ID、昵称、头像、手机号这些不敏感的字段在 Service 层做转换。同理创建订单时前端传过来的数据也应该用 DTO 接收避免前端传了什么乱七八糟的字段直接落到数据库。2.2 前端项目结构前端用 Vue CLI 创建项目目录结构如下src ├── api # 封装axios请求 ├── assets # 静态资源 ├── components # 公共组件 ├── router # 路由配置 ├── store # Vuex状态管理 ├── views # 页面视图 │ ├── home # 前台页面 │ ├── admin # 后台页面 │ └── user # 用户中心页面 ├── utils # 工具函数 └── App.vue这里有个实操经验api目录下的每个模块文件建议按业务拆分。比如homestay.js专门放房源相关的请求order.js专门放订单相关的请求不要把所有 axios 请求都堆在一个文件里。后期维护的时候你会发现这个习惯能省很多事尤其答辩前改 bug快速定位要改哪个接口比什么都重要。axios 封装方面我统一在请求拦截器里加 token在响应拦截器里处理状态码。核心代码如下import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截附带token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error)) // 响应拦截统一处理错误码 service.interceptors.response.use(response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) if (res.code 401) { localStorage.removeItem(token) router.push(/login) } return Promise.reject(new Error(res.message)) } return res }, error { Message.error(网络异常请稍后重试) return Promise.reject(error) }) export default service2.3 为什么单独强调跨域配置前后端分离项目百分之百会遇到跨域问题。你的前端跑在 8080 端口后端跑在 8081 端口浏览器默认会拦截不同端口的请求。解决办法有两种后端加 CORS 配置或者前端用 Vite/Webpack 代理。我推荐两个都做前端开发时走代理更舒服线上部署时后端放开 CORS 保证API能被外部访问。后端 CORS 配置用 SpringBoot 的WebMvcConfigurerConfiguration 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); } }前端 Vite 配置代理则是在vite.config.js里设置server: { port: 8080, proxy: { /api: { target: http://localhost:8081, changeOrigin: true } } }这样开发时前端请求/api/homestay/list会被代理到http://localhost:8081/api/homestay/list浏览器看到的是同源请求不会触发跨域拦截。3. 核心功能模块设计与业务实现3.1 用户认证与权限控制认证方案我选的是 JWT而不是传统的 Session。原因有两个前后面分离的项目用 Session 得自己处理 Cookie 跨域问题麻烦JWT 天然支持无状态认证后端不用存会话记录适合后面扩展移动端。具体流程用户登录时后端校验用户名密码通过后生成一个 token 返回给前端。token 里包含了用户 ID、用户名、角色这些关键信息用 HMAC 密钥签名防止篡改。前端拿到 token 存到 localStorage每次请求在请求头带上。后端写一个拦截器解析 token把用户信息放进ThreadLocal里后续业务代码直接取。JWT 工具类和拦截器示例public class JwtUtil { private static final String SECRET your-secret-key; private static final long EXPIRE_TIME 7 * 24 * 60 * 60 * 1000; public static String createToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }权限控制除了 JWT 拦截器还要在 Spring Security 里配置哪些接口可以匿名访问、哪些需要登录、哪些需要管理员权限。比如/api/login和/api/homestay/list应该放行/api/admin/**需要管理员权限/api/order/**需要登录。我用的是注解方式PreAuthorize(hasRole(ADMIN)) GetMapping(/admin/statistics) public Result statistics() { ... }有一个坑必须提醒Spring Security 默认拦截所有请求如果你忘记在 configure 方法里放行静态资源和登录接口前端页面会一直 401。调试的时候先看控制台有没有输出 permitAll 相关的日志通常能快速定位。3.2 民宿列表与搜索功能的实现民宿列表是前台的核心页面。用户进来首先看到的就是一堆房源卡片点击进去才是详情。列表页要做到支持按城市、入住日期、退房日期筛选支持按价格排序、按评分排序分页展示后端的查询接口用了 MyBatis Plus 的分页插件代码如下public PageHomestayVO searchHomestay(HomestayQuery query) { PageHomestay page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperHomestay wrapper new LambdaQueryWrapper(); // 城市筛选 if (StringUtils.isNotBlank(query.getCity())) { wrapper.eq(Homestay::getCity, query.getCity()); } // 关键词模糊搜索 if (StringUtils.isNotBlank(query.getKeyword())) { wrapper.like(Homestay::getName, query.getKeyword()) .or().like(Homestay::getDescription, query.getKeyword()); } // 价格排序 if (asc.equals(query.getPriceOrder())) { wrapper.orderByAsc(Homestay::getPrice); } else if (desc.equals(query.getPriceOrder())) { wrapper.orderByDesc(Homestay::getPrice); } wrapper.eq(Homestay::getStatus, 1); // 只展示已上架房源 PageHomestay result homestayMapper.selectPage(page, wrapper); // Entity转VO补充房东名称、评分等信息 ... }前端列表页用 Element UI 的el-table或者卡片式布局这里我建议首页用卡片式而非表格。民宿页面用表格会显得很 Low卡片配上图片、价格标签、评星组件视觉效果好很多。图片上传用的是本地存储方案把文件保存到服务器指定的 upload 目录数据库里只存相对路径访问时通过接口拼接完整 URL。面试的时候如果被问图片怎么做防盗链你就可以顺着讲通过过滤器校验请求来源或者用 CDN 加鉴权。3.3 订单流程与状态机设计订单是整个系统最复杂的模块因为一个订单要经历多个状态而且状态流转不是随意的。我在 Service 层专门写了一个OrderStatusHandler来管理状态流转保证业务逻辑清晰。订单状态我定义为状态码含义可执行操作0待付款取消订单、去支付1已付款/待入住办理入住、申请退款2已入住办理退房3已完成发起评价、删除订单4已取消无5已退款无创建订单的接口要处理几件事校验房态、计算价格、生成订单号、扣减库存。订单号生成我用的是时间戳加随机数的方案因为并发量小没必要引入分布式ID框架。但要注意库存扣减必须放在创建订单这一步做否则会出现超卖同一时间两个人订最后一间房都查到了还有库存都创建了订单实际上房间已经不够了。这属于并发问题答辩的时候被问到概率很高建议用数据库的行锁处理// 强制走主键索引并对该行加锁 HomestayRoom room roomMapper.selectForUpdate(roomId); if (room.getStock() - roomNum 0) { throw new BusinessException(库存不足); } room.setStock(room.getStock() - roomNum); roomMapper.updateById(room);selectForUpdate对应 SQL 里的SELECT ... FOR UPDATE在同一事务里会锁住这行记录其他事务必须等当前事务提交或回滚后才能继续操作。这种方案在毕设场景下够用也体现了你对并发控制的理解。支付模块我不建议真接支付宝或者微信支付毕设演示申请不到商户号而且回调逻辑调试成本高。常规做法是做一个模拟支付点击去支付弹窗显示支付二维码图片点击模拟支付成功直接把订单状态改成已付款。系统设计上保留transaction表和支付回调接口的扩展位答辩时说明真实支付环境只需要替换支付服务实现即可。3.4 后台管理模块的核心功能后台管理界面主要给管理员和房东用功能点拆开看就这些房源管理新增房源、编辑房源信息、上下架操作。房东只能管理自己的房源管理员可以审核所有房源。审核状态有三种0待审核、1已通过、2已驳回。房源必须通过审核才能在前台展示。订单管理查看所有订单、按订单号搜索、处理退款请求。用户管理用户列表、禁用/启用账号。禁用后对应的 token 在下一次请求时会因为校验用户状态而被拦截。数据统计用 ECharts 展示近30天订单量、销售额、热门民宿 Top10。这个页面很能撑场面答辩演示的时候放出来老师会觉得你做了真实的数据分析。后台的权限控制比较细。一个普通的民宿主登录后台应该只看到自己的房源和订单而不是所有人的数据。我用 MyBatis Plus 的LambdaQueryWrapper在 Service 层加条件比如房东查订单时额外带上eq(Order::getOwnerId, currentUserId)。不要图省事把全局数据返回给前端再过滤那样既慢又不安全。4. 数据库表设计详解4.1 核心表结构数据库总共八张表每张表的字段都有讲究。用户表的核心字段包括id、username、password、nickname、avatar、phone、email、role、status、create_time。角色字段用字符串USER和ADMIN区分也可以用数字。我建议用字符串可读性好也不会出现不知道 1 和 2 分别代表什么的情况。民宿表的核心字段有id、owner_id、name、description、city、address、cover_image、images、facilities、price、holiday_price、rating、status、audit_status、create_time。images字段可以用 JSON 数组存多张图片MySQL 5.7 以上支持 JSON 类型但更通用的做法是用逗号分隔字符串前端取的时候 split 一下就行。facilities字段同理存 WiFi、停车、厨房等设施标签前端用 tag 组件展示。订单表除了前面讲的状态和价格字段还要加create_time、pay_time、checkin_time、checkout_time。这四个时间字段记录了订单从创建到完成的全过程后续统计和查询都非常有用。评价表关联订单和民宿id、order_id、user_id、homestay_id、rating、content、images、create_time。这里要注意一个逻辑一个订单只能评价一次所以order_id要加唯一索引。避免用户刷单给自己民宿刷好评。4.2 外键到底要不要加这是我做项目时犹豫最久的一个点。实际在公司项目里外键约束用得越来越少因为分布式场景下数据库很难维护跨库的强一致性。但毕设项目是单库单表加外键反而能体现你的数据库功底而且防止脏数据。我的建议是主外键关系如订单表关联用户ID、民宿ID加上外键约束业务关联关系如评价表和民宿表的关联不强制加。理由是订单数据是核心业务数据必须保证引用的用户和民宿真实存在而评价和民宿之间的关联即使断了也不会导致致命问题最多就是查不到对应民宿而已。4.3 SQL 索引设计注意事项索引是数据库设计的第二道保险。民宿表的city字段和status字段组合索引要建因为用户搜索最常见的就是某个城市已上架。订单表的user_id和status联合索引也要建因为用户查自己的订单列表是这个条件。创建时间索引用于排序数据量大了以后查询ORDER BY create_time DESC不会全表扫描。索引不是越多越好。每个索引都会占用存储空间并在写入时增加维护成本。毕设数据量一般不大建三到五个索引足够了重点覆盖查询最频繁的业务路径。5. 前后端核心代码实现拆解5.1 后端统一返回结果与全局异常处理为了让前端处理数据方便我自定义了一个统一返回体public class ResultT { private Integer code; // 200成功其他为失败 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(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }全局异常处理用的是RestControllerAdvice把业务异常、参数校验异常、系统异常分别处理。这样前端拿到的永远是结构统一的 JSON不会出现某些接口返回{code:200}另一些接口又返回{success:true}的情况。5.2 前端路由守卫与权限控制前端路由守卫需要同时处理两个问题用户是否已登录以及用户是否有权限访问当前页面。在router/index.js里配置路由时给后台页面加一个meta: { requiresAuth: true, roles: [ADMIN] }标记然后在全局前置守卫里检查router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) return } if (to.meta.roles to.meta.roles.length 0) { const role localStorage.getItem(role) if (!to.meta.roles.includes(role)) { next(/403) return } } next() })这个守卫配合后端 JWT 鉴权形成双重保护。前端守卫只是用户体验层面的过滤后端接口鉴权才是真正的安全防线。答辩时如果被问到前端路由守卫能不能替代后端权限控制答案显然是不能因为接口是可以被直接调用的绕过前端页面照样能访问API。5.3 关键技术点文件上传与静态资源映射民宿图片上传是前后端配合的一个典型场景。前端用 Element UI 的el-upload组件设置action属性指向后端的上传接口。后端接收MultipartFile保存到本地指定目录返回图片访问路径。后端配置静态资源映射这样图片路径就能直接访问Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir); } }这里有个细节上传目录在配置文件中定义不要硬编码在代码里。因为部署环境不同Windows 和 Linux 的路径分隔符不一样写死的话换环境就崩。我习惯在application.yml里配置file: upload-dir: ./upload然后通过Value(${file.upload-dir})注入使用。5.4 数据统计模块的 SQL 实现后台的数据统计模块最常用的就是两个 SQL每日订单量和每日销售额。用 MySQL 的DATE_FORMAT处理时间字段SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, COUNT(*) AS orderCount, SUM(total_amount) AS salesAmount FROM order WHERE create_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY day ORDER BY day;这里注意order是 MySQL 的保留字表名加反引号包裹否则语法报错。我当时就因为这个卡了一会儿排查半天才发现是表名冲突。6. 实操过程与部署避坑指南6.1 本地开发环境搭建开发环境建议JDK 1.8 或者 11、Maven 3.6、MySQL 5.7 或者 8.0、Node.js 14、IDEA 和 VSCode。JDK 版本别图新如果你用的 SpringBoot 是 2.x配 JDK 8 是最稳的。SpringBoot 3.x 要求 JDK 17框架版本和JDK版本必须匹配很多同学项目跑不起来都是因为这里不匹配。数据库连接配置有几点容易踩坑spring: datasource: url: jdbc:mysql://localhost:3306/homestay?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.DriverserverTimezoneAsia/Shanghai不加会报时区错误allowPublicKeyRetrievaltrue是 MySQL 8.0 连本地数据库时需要的少了会提示公钥检索失败。6.2 前端依赖安装与启动前端拿到项目先在根目录执行npm install这一步经常出现各种问题。比较常见的是网络原因导致依赖下载失败解决办法是切换国内镜像源npm config set registry https://registry.npmmirror.com如果之前装过旧版本的依赖导致 node_modules 混乱可以删掉node_modules文件夹和package-lock.json重新执行安装。这个操作虽然粗暴但确实有效我遇到莫名其妙的启动报错基本都是这么解决的。前端启动命令是npm run serve默认跑在 8080 端口。如果端口被占用可以在vue.config.js里改端口module.exports { devServer: { port: 8080 } }6.3 常见启动报错排查启动报错是最消磨耐心的事情这里整理一份问题速查表报错信息原因解决办法Port 8080 was already in use端口被占用换端口或者杀掉占用进程Failed to configure a DataSource数据库连接配置不对检查 yml 里的 URL、用户名、密码java.sql.SQLException: Unknown database数据库还没创建先执行建库语句再启动Invalid bound statement (not found)MyBatis映射文件路径不对检查 Mapper 接口和 XML 的 namespaceWhitelabel Error Page后端接口异常但没全局异常处理检查全局异常处理器是否配置npm ERR! code ERESOLVE依赖版本冲突删除 lock 文件重装依赖遇到错误不要慌先看控制台最底层的异常栈。很多人一报错就截图扔群里问其实大多数问题通过看日志都能自己解决。比如Invalid bound statement大概率是 Mapper XML 没有打包到 target 目录在pom.xml里加这段就能解决build resources resource directorysrc/main/resources/directory /resource /resources /build6.4 打包部署流程项目开发完了部署是另一个考验。前端打包生成本地静态文件npm run build打包完成后生成dist目录。如果你用 Nginx 部署把dist目录放到 Nginx 的 html 目录下并配置反向代理server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/dist; index index.html; try_files $uri $uri/ /index.html; # 解决Vue路由刷新404 } location /api/ { proxy_pass http://localhost:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /usr/local/homestay/upload/; } }Nginx 这块注意try_files配置。Vue Router 默认使用 History 模式刷新非首页路径时 Nginx 找不到对应的物理文件就会返回 404try_files $uri $uri/ /index.html就是把这个情况统一回退到index.html让前端路由接管。后端打包用 Mavenmvn clean package -DskipTests生成的 jar 包在target目录下直接运行java -jar homestay-system.jar --spring.config.locationapplication.yml7. 作业收尾与答辩准备建议7.1 演示数据的准备技巧答辩演示的时候最尴尬的场面就是页面上空荡荡的没有数据可以展示。项目开发阶段就要准备一套完整的演示数据至少十个城市、每个城市两到三个民宿、每个民宿三四个房型、若干条已完成订单和评价。我建议写一个data.sql或者直接用现成的 SQL 脚本导入数据不要太大但要覆盖各种状态。演示的时候按照这个顺序走比较流畅首页展示民宿列表搜索一个城市点击进入详情选择入住日期和房型提交订单去模拟支付订单变成已付款切到后台审核房源最后打开数据统计页展示图表。整个流程走下来大概五分钟能覆盖系统百分之八十的功能。7.2 答辩老师常问的问题准备把几个高频问题提前想好答案答辩的时候心里有底为什么用 JWT 而不用 Session答前后端分离项目无状态认证更合适JWT 天然支持分布式扩展Token 存在前端后端不需要维护会话。订单并发问题怎么解决答数据库行锁 事务通过SELECT ... FOR UPDATE锁住房源库存行防止超卖。密码是怎么存储的答BCrypt 哈希加密不存明文密码找回通过重置而不是找回。图片上传怎么处理答本地上传目录 Nginx 静态资源映射数据库存相对路径。如果访问量大了怎么办答接口层可以做 Redis 缓存热点民宿数据搜索接口用 Redis 做缓存数据库加索引后续可引入消息队列削峰。7.3 从毕设到项目经验的延伸做完这个系统你可以把项目经验写进简历里。写的时候要突出业务复杂度和技术亮点擅长的地方往深了写参与不多的地方别硬堆。比如你实现了基于 Redis 的民宿热度排行那就在简历里明确写使用 Redis ZSet 实现民宿热度排行日均处理数据量 XX 条这是面试官能看到的真实能力。如果还有余力扩展建议往这几个方向延伸接入真实的第三方登录微信扫码登录、用 WebSocket 做房东和游客的在线聊天、引入 Elasticsearch 做民宿搜索的全文检索。每一项扩展都能成为下次面试的深挖点也让这个毕设不止步于交差。7.4 个人踩坑心得最后分享几个做这个项目时最深刻的体会。第一个是数据库命名规范。表的字段名统一用小写下划线风格比如create_time、owner_id。MyBatis Plus 默认开启了驼峰映射能把create_time自动转成 Java 里的createTime属性。如果你一会儿用下划线一会儿用驼峰会出现字段映射不上、查询结果全是 null 的诡异问题。第二个是前端提交表单时的数据校验。金额字段、日期字段这些类型一定要在前端和后端同时校验不要觉得前端做了一道就万事大吉。攻击者可以直接构造请求调用接口后端的参数校验才是最后一道防线。Spring 的Validated注解配合 DTO 里的NotNull、Min、DecimalMin这些约束写起来不费劲但能挡住大量低级错误。第三个是版本管理。从一开始就建立 Git 仓库每个功能模块完成后做一个有意义的 commit。我在做项目的过程中吃过不少次亏改崩了代码没法回滚只能一点一点重新调试。有了 Git 之后每次大幅重构前先建个分支折腾坏了直接切回来心态完全不一样。这套系统我从数据库建表到前后端调通前前后后花了两周左右的时间。核心代码量大概五千行不算多但业务链路完整从游客下单到房东管理再到平台运营每一块都是能讲出故事的现实场景。如果你正在为毕设选题头疼这个方向真的值得考虑。照着上面的思路一步步来做完你会发现毕设不仅是为了拿学分更是你第一次完整地当一回全栈工程师。