1. 项目概述与需求分析1.1 为什么做旅游民宿管理系统做这个系统的起因很直接身边一个做民宿的朋友旺季的时候每天要接几十个电话、回几十条微信消息订单记在本子上还经常出错房间有没有卖出去全靠脑子记。我当时就想这不就是一个典型的业务管理系统吗房源管理、订单管理、客户管理、价格管理这些需求聚合到一起用Spring Boot Vue来做一套前后端分离的管理系统再合适不过。市面上的旅游民宿管理系统不少但要么是SaaS平台按年收费要么是功能臃肿用不上。自己做一套的好处是可控性极强想加字段就加字段想改逻辑就改逻辑数据在自己手里后续接小程序、接公众号都方便。这套系统适合谁适合有Java后端基础、想系统学习Spring Boot Vue全栈开发的人也适合民宿运营者想自己搭建一套小型管理后台。1.2 核心需求拆解旅游民宿管理系统核心关键词是“旅游”和“民宿”。旅游意味着有淡旺季、有不同的客源渠道民宿意味着房间数量少、房型多样、每间房的差异化定价。结合这些特征我在做需求分析时把系统拆成了几个核心模块民宿信息管理、房间房型管理、在线预订管理、订单管理、客户管理、评论管理、数据统计。每个模块往下再拆民宿信息管理要支持多门店因为很多民宿老板不止一家店房间管理要支持按日期设置价格因为周六日和节假日价格完全不同订单管理要处理预订、入住、退房、取消、退款这几个状态流转数据统计要能按天、按月看入住率和营收。把这些需求梳理清楚系统的大框架就出来了。还有一个关键点面向的管理者是谁民宿的工作人员不是程序员。所以操作界面必须简单直接不能像给程序员用的后台那样满屏英文缩写。这也是我后来在Vue前端设计中重点考虑的因素。2. 技术选型与系统架构设计2.1 为什么选Spring Boot VueSpring Boot和Vue的组合放到今天已经是Java全栈开发的黄金搭档。Spring Boot解决了传统Spring配置繁琐的问题内嵌Tomcat、自动配置、开箱即用做一个管理系统的后端服务非常顺手。Vue则是渐进式JavaScript框架组件化开发让页面拆解和维护变得清晰配合Element UI组件库做后台界面效率极高。相比用若依这类现成框架我这次选择从零搭建原因有两点一是若依默认集成了一堆用不上的功能二次开发时需要踩坑理解它的封装逻辑反而费劲二是从零搭一遍能对每个环节都心里有数后期扩展也好控制。当然如果是企业级快速交付直接用若依改是明智的选择这取决于你的目标是什么。前后端分离的架构让我在开发时能并行工作前端用Vite起开发服务器后端用Spring Boot跑接口通过代理转发解决跨域。部署时前端打包成静态文件交给Nginx托管后端打成Jar包运行整体结构干净利落。2.2 系统整体架构设计这套系统的架构分为四层接入层、应用层、服务层、数据层。接入层是Nginx负责托管前端静态资源、反向代理后端接口、配置HTTPS证书应用层是Vue单页应用负责页面渲染和用户交互服务层是Spring Boot提供的RESTful API处理业务逻辑数据层使用MySQL存储业务数据Redis做缓存。我画一下数据流向用户在浏览器打开管理系统输入账号密码登录Vue把凭证存到localStorage之后每次请求在拦截器里自动带上Token。后端通过拦截器校验Token合法性校验通过后分发到对应的ControllerController调用Service处理业务逻辑Service访问Mapper操作数据库返回结果逐层回传。整个链路清爽、职责清晰。为了应对后续可能的并发量增长我在设计时预留了扩展点Redis缓存热点数据比如房型价格和可订房量减少数据库压力MQ做异步解耦比如订单创建成功后发短信通知不至于让下单接口被外部系统拖慢。这些不是上线必须的但架构上留好位置后面加功能不用推倒重来。2.3 数据库表结构设计数据库是这套系统的地基表结构设计直接决定业务逻辑的复杂程度。我梳理下来核心表有这几张用户表管理员和前台共用一个表用角色区分、民宿门店表、房间表、房型表、房间价格表、订单表、订单状态记录表、评论表。以订单表为例我分享几个关键字段的设计考量订单编号order_no用业务前缀加时间戳加随机数生成保证唯一且可读性强订单金额拆成原价total_amount、实付金额pay_amount、优惠金额discount_amount三个字段方便后续对账和营销活动统计状态字段status用整型存0待支付、1已预订、2已入住、3已退房、4已取消、5已退款可读性和扩展性都比较好。房间价格表是这套系统的特色因为民宿的房价在淡旺季相差很大我设计成按天存价格日期作为主键的一部分room_id date price。这样在展示日历时可以直接查询某段日期每天的房价在用户选日期时也能精确计算出总价。缺点是数据量会随日期增长但民宿房间数量有限一天最多几百条记录完全撑得住。3. 后端Spring Boot核心实现3.1 项目初始化与依赖配置后端我用Spring Initializr创建项目几个关键的依赖必须讲清楚spring-boot-starter-web提供Web能力、mybatis-plus-boot-starter持久层框架我们这里用的MyBatis-Plus就是为了少写XML、mysql-connector-java数据库驱动、spring-boot-starter-validation参数校验、jjwt生成和解析JWT Token、hutool工具类库处理日期、生成编号很方便。MyBatis-Plus的选择值得多说一句民宿管理系统的CRUD操作占了绝大多数MyBatis-Plus的单表操作几乎不用写SQL直接把Mapper接口继承BaseMapper就能用。复杂查询我用注解或者XML写省下的时间非常可观。它还内置了分页插件管理后台的列表分页直接调用方法就行。Spring Boot的配置文件我强烈建议用YAML格式比properties清晰得多。关键配置项有数据源连接信息、MyBatis-Plus的日志输出开发环境开启方便调试、JWT的密钥和过期时间、自定义的跨域配置。我在application.yml里把Redis和短信通知等外部服务的配置也预留了位置方便后续接入。3.2 统一返回结果与异常处理一套好的接口体系返回结果结构必须是统一的。我定义了一个Result类包含code状态码、message提示信息、data业务数据三个字段。成功返回code为200业务错误返回400未登录返回401服务器错误返回500。这样前端拿到结果后先判断code再处理数据逻辑非常统一。异常处理我用RestControllerAdvice做了全局拦截。自定义的业务异常比如房间已被预订、订单状态不支持当前操作抛出BizException全局异常处理器捕获后返回对应的错误信息和状态码系统异常空指针、数据库连接失败返回500同时把详细异常信息打印到日志方便排查。前端不用每个请求都写一堆错误判断逻辑只管在拦截器里统一提示错误信息。这一步很多新手容易忽略觉得接口能跑通就行。但实际联调时全局异常处理和统一返回真的能省无数扯皮的时间。前端拿到不明不白的异常堆栈时根本没法用只有统一了错误格式前后端协作才高效。3.3 JWT登录认证实现民宿管理系统的用户分两类系统管理员和门店工作人员。考虑到后面可能开放给民宿用户自己下单我直接在登录认证上就考虑了多角色。JWT的结构是Header.Payload.Signature三段式我用jjwt库来生成和解析Token密钥存在配置文件中用HS256算法签名。登录接口的逻辑是接收用户名和密码用BCrypt加密算法比对密码千万别用MD5存密码太容易被撞库了比对成功后生成JWT返回给前端。Token里我放了用户ID和角色信息过期时间设置为24小时。用户在有效期内的操作不需要重新登录过期后前端拦截到401状态码自动跳转到登录页。后端考虑到接口安全我写了一个JwtInterceptor拦截器注册到Spring MVC的拦截器链中配置excludePathPatterns放行登录接口和获取民宿公开信息的接口。拦截器里从请求头取Token解析成功就放行失败返回401。这里有个小技巧解析完Token后把用户ID放到Request域的Attribute中后续Controller和Service里就能直接取到当前操作人不需要再查一次数据库。3.4 房间管理与预订核心接口房间管理模块的接口我按照RESTful风格来设计GET /api/rooms获取房间列表、POST /api/rooms新增房间、PUT /api/rooms/{id}修改房间信息、DELETE /api/rooms/{id}删除房间逻辑删除为的是保留历史订单数据。查询条件支持按门店、按房型、按状态筛选配合MyBatis-Plus的条件构造器写起来非常顺手。预订流程是这套系统的核心业务我单独讲讲。用户提交预订请求时前端传来民宿ID、房型ID、入住日期、离店日期、入住人信息。后端校验日期合法性入住不能早于今天、离店必须晚于入住然后计算出总房价创建订单状态设为待支付。这里的关键是防止超卖同一房型在同一时间段内不能重复预订。防超卖的实现我用了数据库层面的乐观锁。订单表里加了一个version字段更新房间状态时带上条件UPDATE room SET status1, versionversion1 WHERE id#{id} AND version#{version}如果影响行数为0说明已经被别人抢先了就提示用户房间已被预订。这种方式比悲观锁性能好对民宿这种低并发场景完全够用。4. 前端Vue核心实现4.1 项目创建与工程化配置前端我用Vite来创建Vue 3项目命令是npm create vitelatest tourism-hotel-admin。对比WebpackVite在开发环境的启动速度和热更新效率是碾压级的配备Vue 3的Composition API写起业务来也更灵活。项目创建完第一件事是装依赖vue-router前端路由、pinia状态管理、axiosHTTP请求库、element-plusUI组件库、dayjs日期处理、echarts图表统计。Element Plus是Element UI的Vue 3版本后台管理系统的表单、表格、弹窗、日期选择器这些组件直接拿来用项目开发效率翻倍。工程化方面我做了几个配置路径别名指向src目录不用再写一长串相对路径代理转发在vite.config.js里配置开发环境把/api开头的请求转发到http://localhost:8080解决开发时的跨域问题eslint和prettier用来约束代码风格多人协作时不至于代码风格乱七八糟。4.2 前端页面结构与路由设计页面结构上我采用了后台管理系统最经典的布局左侧是侧边栏菜单菜单项根据地动态渲染不同角色看到不同的菜单顶部是导航栏展示系统名称和管理员信息主体区域是内容展示区使用路由视图切换。这种布局对管理者来说非常直观点击左边菜单右边直接出现对应内容。路由设计上我做了路由懒加载每个页面的组件单独打包成独立的Chunk首屏只加载必要的资源加载速度有明显的提升。公共页面登录页和需要登录的页面做了区分路由守卫里判断用户是否已登录没登录的强制跳转到登录页。同时做了一层简单的权限控制路由的meta信息里标记需要的角色守卫里比对当前用户角色没有权限的直接跳转403页面。页面组件拆分这块我遵循一个原则一个页面一个目录目录里放index.vue页面主组件和components文件夹页面内的子组件。比如订单列表页我把订单列表、订单详情弹窗、订单状态操作按钮分别拆成独立的子组件每个组件只负责一块逻辑改起来互不影响。4.3 状态管理与接口联调状态管理用的Pinia比Vuex用起来简单太多。我建了三个StoreuserStore存放用户信息用户名、角色、Token、roomStore存放房间和价格的缓存数据、orderStore存放订单的筛选条件和列表数据。UserStore里的Token配合LocalStorage持久化刷新页面后能自动恢复登录状态。接口封装这块我在src/api目录下按业务模块拆分文件room.js、order.js、statistics.js等每个文件里导出一组请求函数。以room.js为例export function getRoomList(params) { return request.post(/api/rooms/list, params) }。请求函数内部统一调用封装的axios实例实例里配置了baseURL、请求超时时间、请求拦截器自动加Token、响应拦截器统一处理错误码。联调过程中最容易出问题的是参数格式。前端用JSON传参后端用RequestBody接收对象里的日期字段是字符串还是时间戳、空字符串要不要传给后端、字段名是驼峰还是下划线这些必须在接口文档里约定清楚。我们的约定是日期传日期字符串yyyy-MM-dd时间戳传Long类型字段命名统一用驼峰后端通过Jackson配置自动处理。4.4 核心业务页面实战预订页面是前端开发中比较复杂的一块因为要集成日历选择和价格联动。我用的Element Plus的日期选择器el-date-picker类型设为daterange选择入住和离店日期。选中日期后前端请求后端获取这段时间的房价列表用表格展示每天的房价底部自动计算总价。价格联动用watch监听日期变化重新计算总价并更新到页面上。订单管理页面用el-table渲染订单列表状态列用el-tag展示不同颜色的标签待支付橙色、已预订蓝色、已入住绿色、已取消灰色。操作列根据状态动态渲染按钮待支付可以取消已预订可以办理入住已入住可以办理退房。办理入住和退房时弹确认框确认后调用对应的接口操作成功后刷新列表。这里有个体验细节表格加上了序号列和分页器数据量大的时候不会卡。数据统计页面用ECharts展示图表。一个折线图展示最近30天的营收变化一个柱状图展示各房型的入住率对比一个饼图展示预订渠道占比。首页的Dashboard用卡片展示几个核心指标今日预订量、今日入住量、本月营收、当前可用房间数。这些数据的获取频率是每次进入页面时拉取由于数据量不大就不做轮询了。5. 高频问题与避坑经验5.1 跨域问题大全前后端分离项目绕不过跨域。开发环境我用Vite的代理解决配置server.proxy把/api转发到后端地址。生产环境我用Nginx配置反向代理location /api { proxy_pass http://127.0.0.1:8080; }。这两层配置能覆盖90%的情况。但是有一种情况要注意后端主动跨域时如果配置了自定义请求头比如Authorization携带Token前端浏览器会先发送OPTIONS预检请求。如果后端没有正确响应OPTIONS请求浏览器就会报跨域错误。让我在这里补充一个细节Spring Boot里需要注册CorsFilter并加上allowCredentials(true)允许携带凭证。注意allowedOrigin不能设为*否则带凭证的请求会被浏览器拦截需要指定具体的域名或使用allowedOriginPatterns。5.2 日期和时间处理的坑民宿系统的日期处理贯穿业务始终最容易踩坑的是时区问题。前端传给后端的是yyyy-MM-dd格式的日期字符串如果后端接收时用Date类型Jackson默认转成UTC时间传到前端就会差8个小时。我的做法是数据库里日期字段用date类型存后端实体类对应字段用LocalDate类型接收前端传参直接传字符串不做隐式转换。另一个坑是日期边界。计算入住天数时我用ChronoUnit.DAYS.between(checkInDate, checkOutDate)这个方法算的是两个日期之间的整天数。如果用户订了1号到3号结果是2天还是3天不同的民宿规则不一样。我在系统里统一做成“按晚计价”入住1号离店3号住了2晚价格为2晚的房费。前端日历组件默认入住当天不可选这样避免很多歧义。5.3 并发抢房与订单状态一致民宿虽然并发不高但热门房型在节假日还是会出现多人同时抢房的场景。我前面提到用乐观锁防超卖但还有一个场景要考虑用户A创建了订单但一直不支付把房间锁定了用户B想订同一房间却被提示无房。这就需要加一个订单自动取消机制。我的方案有两种实现路径第一种是Spring的Scheduled定时任务每5分钟扫描一次超时未支付的订单把订单状态改成已取消释放房间库存第二种是用Redis的过期监听下单时给订单号设置30分钟的过期时间过期后自动触发取消逻辑。考虑到稳定性Redis过期监听依赖 Redis 的 key 过期事件不保证可靠性我选择了定时任务方案简单可靠代码逻辑直白。5.4 Vue项目启动后Network不可用开发时发现Vite启动后Network栏显示不可用局域网里的同事访问不到。这个问题的根源是Vite默认监听localhost不监听局域网IP。解决方法是修改vite.config.jsserver: { host: 0.0.0.0, port: 3000 }监听所有网卡接口。配置完成后启动时终端会输出Network地址局域网内的设备就能通过http://192.168.x.x:3000访问了。如果配置了host: 0.0.0.0后Network还是不可用检查一下电脑的防火墙是否放行了3000端口以及是否处于同一网段。这个情况在Windows系统的公司网络里很常见我踩过一次后就把这个配置固化为新项目的默认模板了。6. 系统部署与上线体验6.1 后端打包与服务器配置后端打包我用的Maven的package命令通过配置Spring Boot Maven插件打出来的Jar包是可直接执行的fat jar里面包含了所有依赖。部署到Linux服务器上我用systemd配置了一个服务单元启动命令是java -jar tourism-hotel.jar --spring.profiles.activeprod这样可以方便地区分开发环境和生产环境的配置。生产环境的配置文件我单独维护application-prod.yml数据源指向云数据库开启优雅停机设置JVM参数止血堆内存512M、最大1G。系统比较轻量资源占用不需要太高。6.2 前端打包与Nginx配置前端打包运行npm run build生成dist目录。把dist目录上传到服务器的/opt/nginx/html目录下修改Nginx配置root指向dist目录try_files配置为$uri $uri/ /index.html这样Vue路由在刷新页面时不会404。HTTPS证书我用的免费证书配置完80端口转发到443后强制所有HTTP请求跳转到HTTPS。这样用户通过https://hotel.example.com访问时前后端都是HTTPS不会出现混合内容警告。整体部署完成后在浏览器里走一遍核心流程登录、查看房间、预订、支付模拟、办理入住退房、查看统计报表测试通过后就可以正式上线了。实测跑下来的体验首页响应时间在50ms以内列表接口的响应时间在100ms左右搜索和筛选没有明显的延迟感。Jar包占用300M内存左右MySQL占用不到200M部署在一台2C4G的小型云服务器上完全没有压力。6.3 后续功能扩展方向这套系统的扩展空间很大我这里罗列几个想清楚的方向小程序端用户自助下单目前是管理员帮用户下单、营销工具优惠券、拼团、老带新、对接支付网关微信支付、支付宝、对接OTA平台美团、携程、飞猪的订单自动同步、经营数据分析的报表深度挖掘。我自己最想优先做的是小程序端。民宿的客人大多数是通过微信或者旅游平台来预订的如果有一个小程序让他们自己选房间、下单、支付民宿老板的接待压力会大大减少。而且小程序端的代码可以在现有Vue项目基础上复用大部分组件工作量不会太大。对接OTA平台的难度会高出不少因为各家平台的接口协议、参数命名、鉴权方式都不同需要逐个适配。但一旦打通订单自动同步到本地系统民宿前台就不用在电脑上装一堆渠道管理软件了。这类功能属于二手阶段建议优先和自己熟悉的平台做对接验证流程稳定了再继续扩展。回到最初做这个项目的体会一套管理系统能否真正落地关键不在于用了多潮的技术框架而在于是否真正理解业务场景、把一个一个细节踩平。Spring Boot Vue是全栈开发者的基本功但把它们灵活运用、和实际业务深度结合才真正考验功力。这套民宿管理系统做完之后我最大的感受是简单的技术组合也能打造出可靠好用的系统。如果你也正在做类似的管理系统多花时间理解业务流程、梳理清楚状态流转、把异常场景想全会比盲目堆技术更有收获。