企业官网建设流程全解析

1. 民宿订单为什么比酒店更难做：先定义好业务边界

我接这套民宿管理系统的时候，第一反应也是“这跟酒店管理差不多，做个房型列表加订单CRUD就行”。真做下去才发现，民宿和酒店的订单逻辑差异比想象中大得多。酒店的定价单位是房型加一晚，订单通常按晚数连续计算，一个房型下有多间房，同一晚卖完就换另一间；民宿则经常是整租或成套出租，一个房型可能就一间房子，用户住的是“这一套房在某几天里不能被任何订单占用”。这意味着所有表设计和接口设计都要围绕“同一房源、连续日期、不可重叠占用”来展开。

这套系统的业务核心，其实就四个对象：房源、日期、价格、订单。四个对象之间有两组硬约束：一组是“房源在某一天只有一种可售状态”，另一组是“订单的入住区间不能重叠”。你把这四个对象和两条约束处理清楚了，民宿管理的八成功力就到手了。

1.1 最小可用业务闭环里有哪些东西

我最终敲定的第一版功能，没有盲目照搬酒店系统，而是先跑通一个真实经营场景的闭环：

• 房源与房型管理：维护房源基础信息、房型（大床房、Loft、整栋别墅等）、设施标签、图片；
• 房态日历：以“天”为单位展示每个房源的“空闲、已订、维修、锁定”状态；
• 订单全流程：用户下单、支付登记、管理员确认、办理入住、办理退房、取消订单；
• 客户管理：记录住客姓名、手机、证件尾号、历史订单，方便二次预订；
• 经营统计：按月查看出租率、间夜数、营收汇总。

注意，这里我特意没有做“渠道分销对接”，比如OTA平台直连、房源自动分发这种能力。原因很简单：民宿渠道对接的复杂度不亚于订单系统本身，各家渠道的价格规则、库存回写协议都不一样，第一版做进去只会让事务边界变得模糊。先做自己的直销订单闭环，后续再逐步扩展，这是更稳妥的演进路线。

1.2 第一版砍掉的功能与取舍逻辑

除了渠道分销，我还砍掉了优惠券营销、复杂财务结算（押金分账、多房东分成）、在线退改流程的自动化审批。砍掉的逻辑不是觉得没用，而是因为订单状态机越复杂，前端表单和后台接口的测试成本就越高。比如优惠券会直接牵扯到“未付款订单的价格快照是否要重算”这类边界问题，多数民宿短租场景根本用不到这种动态改价能力，反而把价格快照做成下单时固定，逻辑简单得多。

这套系统适合谁参考？如果你正在做一个中小型民宿集群的管理后台，或者想快速理解SpringBoot+Vue3前后端分离项目的完整组成，这套结构是一个很合适的骨架。它不堆砌微服务，也不搞分布式缓存，而是把有限的复杂度放在业务规则上——这恰恰是民宿系统真正值得花时间的地方。

2. 技术选型复盘：SpringBoot+Vue3+MyBatis这套组合到底省在哪

技术选型时我给自己的标准是：单人开发或小团队开发，要求快速交付、容易招到能接手的人、部署成本低。在这个标准下，SpringBoot+Vue3+MyBatis+MySQL基本是当前最稳的组合之一。

SpringBoot负责后端接口和事务管理，生态成熟，任何一个做过Java后端的人拿起来都能看；Vue3负责后台管理页面的交互，配合现成的组件库，开发效率很高；MyBatis负责SQL，因为民宿系统的统计报表、多条件订单查询非常多，用MyBatis写动态SQL比JPA的实体映射直观得多；MySQL则是在事务、索引、运维成本之间最平衡的选择。

2.1 具体版本组合与选择原因

我实际用的是这套版本组合，你可以直接照搬：

有人可能会问，SpringBoot 3.x要求JDK17，会不会对部署环境要求太高？实际体验是：一台2核4G的云服务器完全跑得动这套系统，jar包加前端静态文件加起来不到200MB，MySQL单独一台也能跑。没必要为了“兼容旧机器”停留在JDK8，因为新项目没有历史包袱，直接用新版本反而减少后续升级成本。

2.2 为什么ORM选MyBatis而不是JPA

JPA我是用过的，它在实体关系固定的场景下确实省事。但民宿系统有个特点：查询条件极不稳定。后台订单列表可能同时按入住日期、城市、房源、订单状态、手机号、订单号来筛选，临时还可能加一个“近30天未入住的订单”这种需求。这种查询用JPA写Specification或QueryDSL，代码会越来越绕；而MyBatis只需要在XML里堆几个 标签，改起来非常直接。

另外，报表查询经常要JOIN订单表、房源表、房型表三张表，统计每个房源的间夜数。这种SQL我宁愿手写，也不愿意让ORM生成。MyBatis允许你完全掌控SQL，这在报表场景是实打实的优势。

前后端分离的模式在这套系统里体现得很彻底。前端通过HTTP接口调用后端，后端不返回页面模板，只返回JSON。这样做的好处是：前端开发和后端接口可以并行；后续如果要做小程序端或者App端，同一套后端接口可以直接复用，不需要新开项目。

3. 数据库建模：一张日历价格表如何同时管住“房、价、日期”

民宿系统建表最容易犯的错，是把“价格”设计成房源表上的一个普通字段。民宿的房价是会随日期浮动的：周末贵、节假日更贵、淡季便宜，而且同一种房型可能在不同日期执行不同价格。如果你只在房源表放一个price字段，遇到节假日调价就只能改表或者额外建调价记录，查询时还得算“今天到底该用哪个价格”，非常痛苦。

我的做法是单独建一张房态日历表，把“房源、日期、价格、可售状态”绑在一起，一条记录代表“某房源在某一天的价格和可售情况”。这张表既是库存表，也是价格表，还是房态表。下面的建表SQL是核心，你可以直接参考。

3.1 核心表结构与字段说明

CREATE TABLE house_calendar ( id BIGINT PRIMARY KEY AUTO_INCREMENT, house_id BIGINT NOT NULL COMMENT '房源ID', sale_date DATE NOT NULL COMMENT '日期', price DECIMAL(10,2) NOT NULL COMMENT '当日价格', stock INT NOT NULL DEFAULT 1 COMMENT '可售数量，民宿通常为1', status TINYINT NOT NULL DEFAULT 1 COMMENT '1可订 2维修 3锁定', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_house_date (house_id, sale_date), KEY idx_sale_date (sale_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源日历价格表';

订单表我更关注三个字段：check_in、check_out、order_status。这里的退房日期check_out是“不包含”的。比如用户订了7月1日入住、7月3日退房，那实际占用的是7月1日和7月2日两晚。这个约定很重要，如果不统一，后面做日期重叠检测和价格计算都会出错。

CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单号', house_id BIGINT NOT NULL COMMENT '房源ID', house_name VARCHAR(64) NOT NULL COMMENT '下单时房源快照', check_in DATE NOT NULL COMMENT '入住日期', check_out DATE NOT NULL COMMENT '退房日期，不包含', total_night INT NOT NULL COMMENT '总晚数', total_amount DECIMAL(12,2) NOT NULL COMMENT '订单总价', customer_name VARCHAR(32) NOT NULL COMMENT '住客姓名', customer_phone VARCHAR(20) NOT NULL COMMENT '住客手机号', order_status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已确认 2入住中 3已退房 4已取消 5已退款', pay_time DATETIME NULL COMMENT '支付时间', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_house_date (house_id, check_in, check_out), KEY idx_phone (customer_phone) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

订单表里存house_name这种字段，很多人会觉得多余，但这是刻意做的“价格快照”机制。民宿房源的名称、价格会频繁变动，如果订单只关联house_id，退房后房源改个名或者换个设施清单，历史订单展示就会对不上。快照字段虽然冗余，却能保证订单的历史真实性。

3.2 日期重叠校验与索引设计的核心

订单表最关键的索引是idx_house_date (house_id, check_in, check_out)。你可能觉得日期范围查询没法走索引，实际上MySQL对范围条件还是可以使用索引进行区间扫描的。更重要的是，这个索引配合下面这个SQL，可以高效完成“同一房源是否存在日期重叠”的校验：

SELECT COUNT(*) FROM orders WHERE house_id = #{houseId} AND order_status IN (0, 1, 2) AND check_in < #{checkOut} AND check_out > #{checkIn}

这个SQL的重叠判断是整张表的灵魂，我给你解释一下。两个区间[a, b)和[c, d)不相交的条件是b <= c或者d <= a，也就是“前一个区间的结束不晚于后一个区间的开始”或“后一个区间的结束不晚于前一个区间的开始”。那它们重叠的相反条件就是 a < d 且 c < b。放到SQL里，就是check_in < 新订单的check_out 且 check_out > 新订单的check_in。

3.3 用唯一索引兜底，防止并发下的脏数据

即使应用层做了重叠校验，高并发下仍可能出现两个订单同时查到“不重叠”，然后一起提交成功的情况。最粗暴的做法是对orders表的(house_id, check_in, check_out)直接加唯一索引，但这不可行——不同订单完全可以合法地共用同一个房源和入住日期，只要退房日期不同就行。

我的策略是双保险：应用层用上面的SQL做重叠校验，同时给house_calendar表加version乐观锁字段。下单不直接往orders表里写，而是先尝试对house_calendar表里那些日期逐日扣减库存，只要有一个日期扣减失败，整个事务就回滚。这个方案后面细说。

4. 订单核心链路：状态机、防超订和日期冲突检测的实现细节

民宿订单跟普通电商订单不一样，它的核心资源是“时间”，时间是不可再生的。一个订单把7月1日到7月3日的房源占掉之后，这段时间就卖完了，所以状态流转必须严格。我给订单设计了六个状态，每个状态之间的跳跃都有明确条件和日志记录。

4.1 状态机设计与状态流转约束

订单状态的完整流转是这样的：

• 待支付(0)：用户提交订单，锁定房源日历，等待支付；
• 已确认(1)：管理员标记收款成功，或待支付订单支付成功后自动进入；
• 入住中(2)：住客办理入住，此时该房态在日历上显示为“入住中”；
• 已退房(3)：住客退房，房源日历自动释放给后续订单；
• 已取消(4)：待支付状态下用户主动取消，或超时未支付自动取消；
• 已退款(5)：已确认状态下用户取消订单，管理员同意退款后进入。

我在代码里用了一个简单的状态转移校验，确保非法状态流转不会发生。比如已退房的订单不能被改成“入住中”，已取消的订单不能再支付。这个校验放在Service层，前端只是展示，不能作为唯一防线。

private static final Map<Integer, Set<Integer>> ALLOWED_TRANSITIONS = new HashMap<>(); static { ALLOWED_TRANSITIONS.put(0, new HashSet<>(Arrays.asList(1, 4))); ALLOWED_TRANSITIONS.put(1, new HashSet<>(Arrays.asList(2, 5))); ALLOWED_TRANSITIONS.put(2, new HashSet<>(Collections.singletonList(3))); ALLOWED_TRANSITIONS.put(3, new HashSet<>()); ALLOWED_TRANSITIONS.put(4, new HashSet<>()); ALLOWED_TRANSITIONS.put(5, new HashSet<>()); }

4.2 防超订：为什么乐观锁比悲观锁更适合民宿场景

民宿最常见的问题就是“同一间房同一晚被卖了两次”。一般人的第一反应是给订单表加锁，或者用SELECT FOR UPDATE把冲突检测和插入锁在一起。这种做法在小流量下没问题，但它会让事务持有数据库行锁直到提交，一旦高峰期多个订单争抢同一个房源的不同日期组合，很容易死锁，而且扩展性也差。

我采用的是乐观锁批量扣减方案。核心思路：下单就是“抢时间”，抢到就成功，抢不到就提示用户。业务流程分成两步：

1. 在事务里，对从check_in到check_out前一天的所有日期，逐日执行一次update操作；
2. 如果任何一天影响行数为0，说明有人抢先锁定了该日期，直接抛出异常回滚整个事务。

@Transactional(rollbackFor = Exception.class) public void createOrder(OrderCreateDTO dto) { // 1. 校验日期区间合法性 if (!dto.getCheckOut().isAfter(dto.getCheckIn())) { throw new BizException("退房日期必须晚于入住日期"); } // 2. 逐日扣减库存，利用version乐观锁防止超订 LocalDate cursor = dto.getCheckIn(); while (cursor.isBefore(dto.getCheckOut())) { int rows = houseCalendarMapper.deductStock( dto.getHouseId(), cursor, dto.getRoomCount()); if (rows == 0) { throw new BizException(cursor + " 日期已被预订或锁定"); } cursor = cursor.plusDays(1); } // 3. 计算总价并插入订单 // 4. 记录操作日志 }

对应的Mapper SQL是这样写的：

<update id="deductStock"> UPDATE house_calendar SET stock = stock - #{delta}, version = version + 1 WHERE house_id = #{houseId} AND sale_date = #{saleDate} AND status = 1 AND stock >= #{delta} AND version = #{expectVersion} </update>

这个方案的关键点在于，stock >= #{delta}这个条件直接在SQL层完成原子校验，不需要在代码里先查再更新，所以并发场景下不会出现“查的时候有库存、更新的时候已经没了”的竞态问题。每次扣减都要校验version，但注意store的前提是同一事务内对同一个日期只会执行一次update，所以这里的version不需要额外从快照读取，直接再次执行条件更新即可。

4.3 MyBatis动态SQL在实际查询中的用法

订单后台查询是整个系统里查询条件最多的场景，我直接用MyBatis的 和 标签解决，不需要手写一堆字符串拼接。比如订单列表的模糊搜索，动态拼条件非常自然：

<select id="selectByCondition" resultType="OrderVO"> SELECT * FROM orders <where> <if test="houseId != null"> AND house_id = #{houseId} </if> <if test="customerName != null and customerName != ''"> AND customer_name LIKE CONCAT('%', #{customerName}, '%') </if> <if test="customerPhone != null and customerPhone != ''"> AND customer_phone LIKE CONCAT('%', #{customerPhone}, '%') </if> <if test="status != null"> AND order_status = #{status} </if> <if test="startDate != null"> AND check_in &gt;= #{startDate} </if> <if test="endDate != null"> AND check_out &lt;= #{endDate} </if> </where> ORDER BY create_time DESC </select>

注意，XML里的小于号和大于号必须用<和>转义，这个是新手很容易踩的坑。另外，如果查询条件是开放式的日期范围，我建议直接用>=和<，不要用BETWEEN，因为BETWEEN包含两端边界，容易出现日期边界多算一天或少算一天的bug。

5. 前端Vue3落地难点：房态日历、联动计价与权限路由

前端这部分，很多教程都会演示怎么搭登录页、怎么写表格，但真正难的是两个地方：一是房态日历的交互，二是权限路由的落地。我把这两个当成独立的模块来设计，其他的页面基本就是照着UI组件库的例子改改字段而已。

5.1 前端项目结构与请求封装的设计

我采用的前端目录结构非常常规，方便接手的人一眼看懂：

src/ ├── api/ │ ├── request.js # axios实例与拦截器 │ ├── house.js # 房源接口 │ └── order.js # 订单接口 ├── layout/ │ └── MainLayout.vue # 后台主框架 ├── views/ │ ├── login/index.vue │ ├── house/list.vue │ ├── calendar/index.vue │ ├── order/list.vue │ └── dashboard/index.vue ├── stores/ │ ├── user.js # 登录用户、token │ └── calendar.js # 日选取状态 ├── router/ │ └── index.js │ └── permission.js # 路由守卫 └── utils/ └── dict.js # 枚举状态转文字

axios实例的封装是最先做的事。重点有两个：请求拦截器统一带上token，响应拦截器统一处理后端返回的code码。后端的统一返回结构我设计成{ code: 0, message: 'success', data: ... }，code为0表示成功，其他都是业务异常。这样前端拦截器就能统一弹提示，不需要每个接口单独判断。

import axios from 'axios'; const request = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || '/api', timeout: 10000 }); request.interceptors.request.use((config) => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); request.interceptors.response.use( (response) => { const res = response.data; if (res.code !== 0) { ElMessage.error(res.message); return Promise.reject(new Error(res.message)); } return res.data; }, (error) => { if (error.response?.status === 401) { localStorage.removeItem('token'); window.location.href = '/login'; } ElMessage.error(error.response?.data?.message || '网络异常'); return Promise.reject(error); } );

5.2 房态日历组件与联动计价逻辑

民宿后台最核心的交互页面就是房态日历。我放弃了直接拖第三方日历组件，而是自己写一个按月的表格。每一行是一个房源，每一列是一天，单元格颜色表示状态：绿色可订、橙色已订、灰色维修、蓝色选中。这个组件的核心逻辑是连续日期选择。

用户点击一个起始日期，再点击一个结束日期，组件会通过一个Set保存所有选中的日期，然后遍历这些日期去查house_calendar的接口，获取每一天的价格和可售状态。总价的计算不是前端自己乘单价，而是后端一次性返回“从check_in到check_out-1”的逐日价格数组，前端只做展示。

这样做的原因是：民宿的每日价格是存在数据库里的，前端拿单价去乘晚数很容易出错。后端在创建订单接口里已经重新计算总价了，前端的价格展示只作为参考。

function selectRange(date) { if (!startDate.value) { startDate.value = date; return; } endDate.value = date; if (endDate.value <= startDate.value) { ElMessage.warning('退房日期必须晚于入住日期'); resetSelection(); return; } selectedDates.value = getDatesBetween(startDate.value, endDate.value); }

这里要特别留意日期组件的边界。Element Plus的el-date-picker如果配置了value-format="YYYY-MM-DD"，那返回的就是字符串，直接用字符串比较大小是可以的，但如果想对日期做加减，必须转成Date对象再操作，否则会出现“2024-07-31”加一天还是“2024-07-31”这种诡异问题。我在这个项目里踩过一次，后来统一封装了一个dayjs工具函数，所有日期运算走它。

5.3 路由守卫和菜单权限的设计

权限这块我没有引入特别重型的框架，就是基于角色的简单判定。后端登录接口返回用户信息和role字段，前端根据role判断能访问哪些页面。比如店长角色可以看订单和房态，财务角色只能看统计报表。

路由守卫写在router.beforeEach里，核心逻辑是：没登录就去登录页；登录了但访问的是管理页，就校验角色权限；权限匹配失败就跳403。这里最容易被忽视的是动态路由。如果一开始把所有页面都静态注册了，那么用户手动输入URL也能访问，权限就形同虚设。我的做法是：静态路由只放登录页和403页，其他页面全部在登录后根据角色addRoute进去。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (!token && to.path !== '/login') { next('/login'); return; } if (token && to.path === '/login') { next('/'); return; } const userInfo = JSON.parse(localStorage.getItem('userInfo') || '{}'); if (to.meta.roles && !to.meta.roles.includes(userInfo.role)) { next('/403'); return; } next(); });

菜单的渲染也是一样，根据userInfo.role过滤出可见的菜单项，而不是把所有菜单都写死。这样后续加“门店管理员”角色，只要在菜单配置里加一个role数组，就能控制一整片页面的可见性。

6. 联调部署踩坑：跨域、时区、索引失效与慢查询

前后端分离的联调阶段，有一半时间不是在写新功能，而是在处理环境不一致的问题。我挑几个最有代表性的讲，这些都是真实项目中每天会遇到的。

6.1 开发环境跨域与生产环境代理的配置

开发阶段最烦人的就是跨域。前端跑在5173端口，后端跑在8080端口，直接发请求肯定被CORS拦截。我的做法是开发环境用Vite的proxy做代理，前端代码里所有请求路径都是以/api开头，Vite会把匹配到的请求转发到后端。

// vite.config.js server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, // 不需要rewrite，后端接口统一带/api前缀 } } }

生产环境则是用Nginx把静态文件和后端接口统一代理出去。前端构建完后把dist目录放到Nginx的html目录下，Nginx配置一个location把/api的请求转发到jar包服务，这样浏览器访问的是同一个域名，不存在跨域问题，也更安全。

server { listen 80; server_name your-domain.com; root /opt/frontend/dist; 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; } }

try_files那行是专门为SPA应用准备的，刷新某个子路由时不会404。如果不写这一行，用户刷新订单列表页会直接白屏，这是前后端分离项目最典型的生产问题。

6.2 时区、日期序列化和慢查询的典型问题

MySQL时区问题是个老坑。连接串里如果没有指定serverTimezone，默认用的可能不是中国时区，导致查询结果里的时间比实际慢8小时。我的连接串统一这样写：

jdbc:mysql://localhost:3306/homestay?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

allowPublicKeyRetrieval=true是MySQL 8.0用新的认证插件时需要加的，不加的话连MySQL 8.0会报Public Key Retrieval is not allowed。这个参数如果不加，本地连不上，生产环境倒是可能正常，排查起来很迷惑。

关于订单日期的比较，我一直坚持用字符串。前端传“2024-07-01”这种格式的字符串，后端用LocalDate.parse解析成LocalDate，然后存到MySQL的DATE字段，全程不带时间部分。这样既避免时区问题，又避免LocalDateTime序列化时出现“2024-07-01T00:00:00”这种难看的格式。如果真的需要展示时间，比如订单创建时间，我就在Jackson配置里统一格式化：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

慢查询这块也值得说。订单列表如果数据量到了几万条，多条件查询的COUNT语句可能会明显变慢。我排查时发现，orders表上虽然有idx_house_date，但很多查询条件用的是customer_phone这种字段，如果经常按手机号搜订单，要给这个字段单独建索引。另外，不要在WHERE条件里对日期列做函数运算，比如DATE(check_in) = '2024-07-01'，这样会把索引废掉，正确写法是check_in >= '2024-07-01' AND check_in < '2024-07-02'。

我的经验是，民宿系统上线后优先打开MySQL慢查询日志，阈值设置为1秒，运行两周后基本就能知道哪些查询需要加索引、哪些SQL写法需要重写。很多时候问题根本不是接口代码，而是SQL扫描了太多行。

写到这里，我还想补充一个很多人忽略的小技巧：订单状态和房态日历的状态要保持双向联动。订单取消后，除了改订单状态，还要把house_calendar里对应日期的stock改回去。这个操作最容易遗漏，一旦遗漏，会出现订单已经取消、但日历上还显示已订的脏数据。我在测试阶段靠写脚本自动扫描才把这个隐患找出来。建议你在设计回调逻辑时，把“释放日历库存”和“订单状态变更”放在同一个事务里，避免中间状态不一致。这套系统整体做下来，我的体感是：民宿管理系统的技术难度不在框架，而在业务规则之间的耦合处理；把日期、价格、订单状态这三样东西管理好，整个项目就稳了一大半。