SpringBoot民宿网络营销系统：从房态管理到营销闭环的设计与实践

去年帮朋友做他那个民宿集群的会员和小程序预订后台时，有个感触特别深：很多做旅游民宿系统的人，一开始都只盯着“房态管理”和“订单CRUD”，做着做着才发现，真正决定这套系统能不能带来收益的，其实是后面的营销链路。标题里这个“springboot基于Java的旅游民宿网络营销系统”，说白了就是要把民宿的展示、预订、支付、评价、会员、优惠券这些环节串成一条完整的线上运营闭环。这篇文章我打算按自己实操过的一个项目复盘来聊：从需求边界怎么切、技术栈为什么这么选，到核心表结构、下单防超卖、定时关单、支付回调幂等这些关键代码怎么落地，再到我踩过的那些坑。如果你正在做同类型的毕设，或者准备给中小型民宿做一套轻量级线上营销管理系统，这应该能帮你少走不少弯路。

1. 先想清楚：民宿网络营销系统到底该做什么

1.1 为什么我没有只做一个“房态管理”就收工

民宿这类业务和标准酒店有一个很大的区别：房间数量少，但每间房的差异很大。同一家店可能有山景房、loft、带小院子的独栋，不同日期价格差异也特别明显，周末、节假日、淡季的价格逻辑完全不同。单纯做一个“房间数量管理系统”很容易，但这样的系统并不能帮民宿业主解决最头疼的问题：如何让淡季不淡、如何让住过的客人再回来、如何让客人愿意发朋友圈帮你做宣传。

所以我在设计这套系统时，把核心从一开始的“管理订单”调成了“围绕订单做营销”。具体来说，系统最终要覆盖的能力是这几块：

• 民宿房源的展示与检索，包括房型、图片、设施、价格日历；
• 在线预订与支付流程，前端用户能自主完成锁房、下单、付款、退款；
• 民宿侧的房态与订单维护，包括改价、取消订单、办理入住、退房；
• 营销工具，包括优惠券、会员等级、积分、分享有礼；
• 内容维护，因为很多订单其实是被一篇攻略或一段短视频内容带来的，后台得能维护文章和推荐位。

这几块串起来之后，客人从看到一个种草视频到完成下单、再到收到一张复购券形成一个促活闭环。如果只做房态和订单，后面的营销能力全都没办法展开，系统价值会少一大半。

1.2 系统面向哪些角色，用例边界在哪

我通常会把用户角色分成三类：游客、民宿运营人员、系统管理员。游客能做的事很多其实不需要登录，比如浏览房源、查看价格、看攻略，这些是引流入口；一旦要下单、领券、写评价、用积分，才需要注册登录并完成身份信息维护。民宿运营人员负责维护房源信息、设置价格、处理订单和退款、创建营销活动；系统管理员更多是一套系统层面上的权限和管理能力，比如人员账号、操作日志、基础参数配置。

这个用例边界非常关键。很多初学项目的人容易把所有操作都丢给“管理员”这一个角色，结果后台成了一个大杂烩，权限完全没法收敛。民宿店长和店员的职责其实是有区别的：店长能调整房价和发放大额优惠券，普通店员只能处理入住、退房和查看报表。所以在设计权限模型时就预留了 RBAC 的位置，Spring Security 结合自定义注解去控制接口粒度，而不是一群人公用一个万能账号。

1.3 砍需求比加需求难，MVP 清单我这样列

做个人项目最容易翻车的地方就是需求失控。我见过不少朋友拿着这个题目，一上来就想做地图找房、在线聊天、智能推荐、多商户平台，结果做了两个月还在搭环境。民宿网络营销系统的核心使命很清楚：“把房源卖出去，让客人再来买”，所以第一版只需要把最最基本的路径跑通。

一期清单很克制，但每一块都把钱和库存这两件事管住了。第二期那些东西其实很多都有现成第三方工具，不一定自研。做系统最忌讳的就是盲目追求“功能多”，而忽略了业务闭环是不是真的跑通了。

2. 技术选型不折腾：这套 Spring Boot 版技术栈是怎么定的

2.1 为什么锁定 Spring Boot 2.7.x 而不是最新版

这个项目我建议直接锁定 Spring Boot 2.7.x，搭配 JDK 8。这里有个很现实的原因：网上大量依赖和资料，包括某些中间件的客户端，都是基于 JDK8 和 Spring Boot 2.x 来测试的。Spring Boot 3.x 虽然已经出来挺久，但它的 javax 到 jakarta 命名空间迁移，会让很多习惯用 javax.servlet 的老开发踩坑，一些没及时升级的 starter 在 3.x 下也会报错。

Spring Boot 2.7.x 本身是一个很成熟的长期维护版本，如果你的环境是 JDK8，这个组合几乎不会遇到版本捣乱的问题。热词里经常有人提“springboot版本太高”带来的各种兼容性问题，我自己也遇到过——新建项目时选了 Spring Boot 3.2，结果一个老版本的 MyBatis 依赖启动直接 NoClassDefFoundError，排查半天才发现是命名空间变了。最后统一回到 2.7.x，所有问题消失。小团队和个人项目，稳定性压倒一切。

2.2 核心组件清单：MySQL、Redis、MinIO 与消息队列的取舍

技术选型不需要多花哨，但每一项都得有明确的使用场景。

为什么消息队列我不选？因为第一版系统在促销瞬间的并发量根本到不了需要削峰的程度。引入 RabbitMQ 或 Kafka 对小型民宿营销系统来说是纯增加运维成本。真要处理“下单后发短信、发微信通知”这种异步操作，Spring 自带的事件机制加上线程池就够了。我见过不少教程硬把一个 ActiveMQ 塞进民宿系统里，消费者也就只打印一条日志，完全是自己给自己找活干。系统设计必须对需求诚实，不需要用中间件数量来撑场面。

2.3 工程结构：按业务模块分包，而不是按技术层分包

很多新手习惯建 controller、service、mapper、entity 这样的大包，然后所有业务类都往这几个包里面堆。一个上千行的 OrderController 就这么诞生了。这个项目我改成了按业务域分包，每个包内部再按照经典分层去写。比如订单相关的代码就放在 order 一带，里面再分 controller/service/dao/entity/dto。

java复制com.example.stay
├── common          // 通用响应、常量、异常、配置
├── security        // JWT 鉴权、登录相关
├── user            // 用户、会员、积分
├── house           // 房源、房型、价格日历
├── order           // 订单、支付、退款
├── marketing       // 优惠券、活动、分享
├── content         // 文章、推荐位
├── statistics      // 运营数据统计
└── admin           // 后台管理员、RBAC 权限

按业务域分包有什么好处？你改订单逻辑时，不需要在十几个 controller 包之间跳来跳去；想统计营销活动数据时，直接在 marketing 包和 statistics 包内找。代码会越来越接近业务语言的边界，后面做代码评审或接手别人代码时，这种结构能省掉大量理解成本。

2.4 数据库表设计与核心实体关系

民宿营销系统最核心的表不是订单表，而是房态日历表。这个表用来记录“哪个房间在哪个日期能不能卖，什么价卖”。我把核心表大致列在这里：

这些表的关系其实并不复杂，但很容易忽略的一个点是把“库存”模型设计对。民宿按“间/夜”售卖，一行 room_stock_calendar 就代表某一间房在某个自然日的一个“可售单元”。如果一间房在某个日期被订单锁定了，库存减为 0，其他客人就没法下单。后面提到的所有防超卖、取消订单释放库存，都是围绕这张表操作的。

3. 核心细节解析：预订、库存和营销活动怎么设计

3.1 房态日历表：从根源上解决“超卖”问题

民宿系统最容易出问题的场景是同一个房间同一天被两个人同时预订成功。如果不做控制，订单是都生成了，民宿却没法履约。为了防止超卖，最简单可靠的做法是把库存的扣减做成数据库层面的条件更新，而不是先查询再判断。

java复制@Override
@Transactional(rollbackFor = Exception.class)
public LockResult lockRoom(LockRoomCommand command) {
    // 期望锁定至少 requiredDays 天
    LocalDate start = command.getStartDate();
    LocalDate end = command.getEndDate();
    List<LocalDate> dates = new ArrayList<>();
    LocalDate cursor = start;
    while (cursor.isBefore(end)) {
        dates.add(cursor);
        cursor = cursor.plusDays(1);
    }

    // 如果锁房失败，则抛出业务异常
    int row = roomStockCalendarMapper.tryLock(
        command.getRoomId(),
        dates,
        1  // 依次扣减1
    );
    if (row == dates.size()) {
        return LockResult.success();
    }
    throw new BizException("所选日期房源已被预订，请更换时间");
}

对应的 MySQL 条件是：

sql复制UPDATE room_stock_calendar
SET stock = stock - 1
WHERE room_id = #{roomId}
  AND sale_date IN ( #{startDate}, #{endDate} )
  AND stock > 0

这条 SQL 的本质是利用数据库行锁和条件更新来保证并发安全。两个请求同时想订同一间房，同一个日期同一行记录上只有一个 update 能成功，另一个会因为 stock > 0 条件不满足而更新 0 行。这样就不需要引入 Redis 分布式锁也能可靠防超卖。

但这里有个隐藏问题：如果入住日期跨好几天，更新多行时中途某一天没库存了怎么办？已经成功更新的这几天就白白扣掉了。好在我用事务把所有更新包在一起，任何一天失败就整体回滚，保证不会出现“订单没创建成功，库存却被扣掉”的脏状态。这也是为什么我要求这个操作必须加 @Transactional 的原因。

3.2 订单状态机：每个状态转换都必须有动作

订单状态不能只在代码里用 if else 散落维护，我定义了一个订单状态枚举，把整条链路固定住。这里我给出一个简化版状态定义：

状态变更的时候不能只是改个 status 字段。比如订单从 WAIT_PAY 流转到 CLOSED，系统要释放对应日期的房间库存；从 PAID 流转到 REFUNDING，系统要检查当前时间是否在免费取消范围内；从 CHECKED_IN 流转到 CHECKED_OUT，系统要把订单实付金额结算进民宿收入统计里。把状态变化和动作绑定在一起，能避免某些情况下业务动作被漏掉。

3.3 优惠券设计：最低使用门槛如何与订单金额联动

说到营销系统，就躲不开优惠券。民宿优惠券和电商满减券逻辑类似，但有一个更麻烦的地方在于：订单实付金额是随入住晚数和房价动态变化的。用户在浏览时可能看到满800减100的券，但他真正下单可能是因为周末价格涨到了900，也可能只订一晚才400多，根本用不了。所以优惠券校验不能放在“用户领券”的时候，必须放在“订单提交计算金额”的时候。

优惠券定义表里，我用几个字段来约束规则：

• type：满减券、折扣券、现金券；
• threshold_amount：使用门槛，单位分；
• discount_amount：满减金额，单位分；
• discount_rate：折扣率，比如 80 表示 8 折；
• valid_days：领取后 N 天有效；
• scope：通用券还是指定房型券。

金额为什么要用“分”而不是“元”？这是很多项目新手最容易忽略的问题。数据库用 DECIMAL 存元虽然也能算，但涉及到四舍五入、浮点误差、折扣分摊时非常麻烦。我把所有涉及金额的列都统一成 bigint，单位是分，前端展示时再除以 100，后端和数据库之间不会出现精度踩坑。

下单时计算优惠后的应付金额流程是这样的：

java复制public PriceResult calculatePrice(OrderCalcRequest request) {
    long baseTotal = request.getNights() * request.getRoomPriceInCents();
    long payable = baseTotal;

    UserCoupon userCoupon = userCouponMapper.selectById(request.getUserCouponId());
    if (userCoupon != null && userCoupon.getStatus() == CouponStatus.UNUSED) {
        Coupon coupon = couponMapper.selectById(userCoupon.getCouponId());
        if (baseTotal >= coupon.getThresholdAmount()) {
            if (coupon.getType() == CouponType.FULL_REDUCTION) {
                payable = baseTotal - coupon.getDiscountAmount();
            } else if (coupon.getType() == CouponType.DISCOUNT) {
                payable = baseTotal * coupon.getDiscountRate() / 100;
            }
            // 为了防止负数，兜底最少支付1分
            payable = Math.max(payable, 1);
        }
    }
    return new PriceResult(baseTotal, payable);
}

这段逻辑有几个细节要强调。券的校验必须要查库里真实数据，不能信前端传来的 amount，否则改个参数就能白嫖系统。优惠券核销动作要放在支付成功回调里做，而不是下单时就把券标记成已用，否则支付超时被关闭后券还得回滚，凭空多出不少问题。所有价格比较都基于分，能避免很多浮点误区。

3.4 会员积分与分享裂变：复购率靠这些细节往上提

住宿这个行业复购周期不短，指望客人每个周末都来不太现实，但积分和会员等级可以做“延迟满足”。我的设计里，用户每消费 1 元累计 1 积分，积分可下次下单时抵扣现金，比如 100 积分抵 1 元。会员等级则根据年度消费金额升级，不同等级对应不同的折扣。

sql复制-- 用户消费后增加积分（示意）
INSERT INTO points_record(user_id, points, biz_type, biz_id, create_time)
VALUES(#{userId}, #{points}, 'ORDER_PAY', #{orderId}, now());

做这个功能时有个很重要的原则：积分流水必须“只增不改”。用户订单退款了，要再写一条负积分流水，而不是直接 UPDATE 删除原来的记录。这样对账时能很清楚地看到所有变动轨迹。民宿老板最怕的就是积分对不上账，一旦没有流水记录，客户投诉只能靠人工糊弄。

分享裂变其实是最“营销”的功能，也比较容易出效果。常见玩法是“老带新”：老用户分享自己的邀请链接，新用户注册并完成第一笔订单后，双方各得一张 50 元无门槛券。实现并不复杂，只需要在用户表里加一个 referrer_id，下单回调时检查新用户是不是通过老用户邀请来的，如果是就给两个人各发一张券。虽然功能看起来简单，但它能有效让住客帮你做传播。

4. 实操过程：核心代码是怎么落地的

4.1 用户登录与 JWT 鉴权：Swagger 如何放行

前后端分离的项目里，登录态我用 JWT 而不是 Tomcat Session。用户在登录接口提交手机号和密码（或验证码），验证通过后后端生成一个 token 返回，前端后续请求带着这个 token 访问。为了避免每个接口都写一遍 token 解析逻辑，我弄了个自定义注解 @RequireLogin，用拦截器统一处理。

java复制@Component
public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        if (!(handler instanceof HandlerMethod)) {
            return true;
        }
        HandlerMethod handlerMethod = (HandlerMethod) handler;
        RequireLogin requireLogin = handlerMethod.getMethodAnnotation(RequireLogin.class);
        if (requireLogin == null) {
            // 没有标注 @RequireLogin 的接口，默认放行
            return true;
        }
        String token = request.getHeader("Authorization");
        // 解析 token，把用户信息放入 ThreadLocal
        LoginUser user = JwtUtils.parseToken(token);
        UserContext.set(user);
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        UserContext.clear();
    }
}

这个设计有一个容易踩的坑：Swagger/Knife4j 的接口文档本身不应该被鉴权拦截。所以注册拦截器时，要主动放行 /doc.html, /webjars/**, /v3/api-docs/**, /swagger-resources/**。不然你在本地连接口文档都打不开，还以为是 Knife4j 配置问题。项目里那些不需要登录的公开接口（首页房源列表、价格日历查询）也不加 @RequireLogin，保持轻量公开。

那谁来决定一个接口要不要登录？靠注解，方法上标了 @RequireLogin 就进入拦截鉴权；没标就放行。Spring Security 在这个项目里我主要用来做密码加密和过滤链配置，业务级权限则通过 @RequireRole 之类的注解去补充。千万不要为了展示技术把 Spring Security 的 Filter 链配得特别复杂，最终的维护成本都在自己身上。

4.2 下单防超卖的并发控制实现细节

前面介绍了基于条件 UPDATE 的锁房，实际代码里还要把它和“创建订单”关联起来。我的流程是：

1. 前端提交下单请求（房间 ID、入住日期、离店日期、入住人数）；
2. 后端先计算总价，然后尝试锁定房态日历；
3. 锁房成功后才创建订单，状态为 WAIT_PAY；
4. 设置支付截止时间，比如 30 分钟，超时未支付再由定时任务把房态释放。

java复制@Transactional(rollbackFor = Exception.class)
public CreateOrderResult createOrder(CreateOrderCommand command, LoginUser user) {
    Room room = roomMapper.selectById(command.getRoomId());
    if (room == null) {
        throw new BizException("房间不存在");
    }
    // 1. 锁库存
    boolean locked = lockRoom(command.getRoomId(), command.getStartDate(), command.getEndDate());
    if (!locked) {
        throw new BizException("手慢了，所选日期已被预订");
    }
    // 2. 创建主订单和明细
    Order order = new Order();
    order.setOrderNo(generateOrderNo());
    order.setUserId(user.getId());
    order.setStatus(OrderStatus.WAIT_PAY);
    orderMapper.insert(order);

    List<LocalDate> dateList = DateRangeUtil.splitDates(command.getStartDate(), command.getEndDate());
    for (LocalDate date : dateList) {
        OrderItem item = new OrderItem();
        item.setOrderId(order.getId());
        item.setSaleDate(date);
        item.setPriceInCents(queryPriceByRoomAndDate(room.getId(), date));
        orderItemMapper.insert(item);
    }
    // 3. 设置 30 分钟后自动关闭
    scheduleCloseTask(order.getId());
    return new CreateOrderResult(order.getOrderNo());
}

这里需要注意一点：如果并发量特别大，比如某个节假日做限量秒杀民宿房，条件 UPDATE 虽然不会超卖，但并发线程可能会因为行锁等待导致数据库连接池被打满。小型项目一般遇不到这个量级，真遇到就需要 Redis 预扣库存，然后异步同步到数据库，但那属于另一套架构了。做项目要判断自己的业务阶段，不要一开始就把架构搞复杂。

4.3 订单支付回调的幂等处理

支付回调是整个系统里最容易出问题的环节。支付宝或微信的通知都是异步发送的，会重试很多次，如果你的回调接口没有做幂等处理，客人支付成功后被系统重复加积分、重复改订单状态，后台数据就乱了。

我在支付回调服务里加了两个保险：

第一，回调处理前先查订单是否已经是“已支付”状态，是就直接返回成功，不再执行后续动作。第二，以“订单号 + 支付流水号”为唯一键插入支付流水表，主键冲突说明已经处理过，直接忽略。

java复制@Transactional(rollbackFor = Exception.class)
public void handlePayNotify(PayNotifyRequest request) {
    String orderNo = request.getOrderNo();
    Order order = orderMapper.selectByOrderNo(orderNo);
    if (order == null) {
        throw new BizException("订单不存在");
    }
    // 幂等判断：已支付直接返回
    if (OrderStatus.PAID.equals(order.getStatus())) {
        return;
    }
    PayRecord record = new PayRecord();
    record.setOrderId(order.getId());
    record.setTransactionId(request.getTransactionId());
    try {
        payRecordMapper.insert(record);
    } catch (DuplicateKeyException e) {
        // 重复通知，直接忽略
        return;
    }
    // 更新订单状态、增加积分、核销优惠券
    order.setStatus(OrderStatus.PAID);
    order.setPayTime(LocalDateTime.now());
    orderMapper.updateById(order);
    memberService.addPoints(order.getUserId(), order.getPayAmountInCents());
    couponService.consumeCoupon(order.getId());
}

这个方案看起来很朴素，但非常稳。很多同学在回调里只判断了订单状态，这是不够的，因为第一次回调如果中途突然抛异常，状态没改成已支付，但订单正文已经做了一些修改，重试时那些修改还会重复执行。用支付流水表做记录，哪怕异常了重试时也能通过唯一键识别出来。

4.4 定时任务：取消超时未支付订单与恢复库存

在 Spring Boot 里做定时任务其实很简单，只需要在启动类加 @EnableScheduling，然后在组件里用 @Scheduled 标注方法。我做了一个 OrderTimeoutJob，每 5 分钟扫描一次超时未支付订单，执行关单。

java复制@Component
@Slf4j
public class OrderTimeoutJob {

    @Resource
    private OrderService orderService;

    @Scheduled(cron = "0 */5 * * * ?")
    public void closeExpiredOrders() {
        List<Order> expiredOrders = orderService.listExpiredUnpaidOrders(30);
        for (Order order : expiredOrders) {
            try {
                orderService.closeOrder(order.getId());
            } catch (Exception e) {
                log.error("自动关闭订单失败, orderId={}", order.getId(), e);
            }
        }
    }
}

这里有一个经验：定时任务里不能因为单个订单处理失败就中断整个循环，否则一个脏数据可能导致后面所有超时订单都无法扫描，所以我给每个订单包了 try/catch，失败了记录下来，等下次扫描再处理。

我用的是 Spring 自带 @Scheduled 单机版，第一次上线完全够用。如果以后部署了多个实例，就会遇到同一时刻多个节点都在跑同一个任务的问题，到时候再引入 XXL-Job 或 ShedLock 也不迟。不要一开始就给两个实例的部署配上分布式任务调度，收益很低。

4.5 Docker 部署与静态资源目录映射

开发调试时每天用 mvn spring-boot:run 没问题，但项目接近完工时会统一放到 Docker 里部署，这样换服务器不用重新折腾 JDK 和 MySQL 环境。

dockerfile复制FROM maven:3.8-jdk-8 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn package -DskipTests

FROM openjdk:8-jre
WORKDIR /app
COPY --from=build /app/target/stay-server.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

用多阶段构建能把 Java 编译环境和运行环境分开，最终镜像很小。真正线上运行的时候，有几个目录必须从容器里面映射出来。一个是上传图片的目录，因为容器本身是无状态的，重建后文件会丢；另一个是日志目录，方便排查问题。

bash复制docker run -d \
  --name stay-server \
  -p 8080:8080 \
  -v /data/stay/upload:/app/upload \
  -v /data/stay/logs:/app/logs \
  --env SPRING_PROFILES_ACTIVE=prod \
  stay-server:1.0.0

这里提醒一个很多人会遇到的问题：如果容器用了 /app/upload 保存用户图片，而 Nginx 又直接映射 Docker 目录做静态访问，后期文件更新时很容易出现权限不一致问题。把配置写在 application-prod.yml 里，使用绝对路径 /data/stay/upload 会更直观。Spring Boot 本身也可以配置资源映射把你本地的 upload 目录暴露为 URL 可访问路径，但在生产环境我更建议交给 Nginx 处理。

5. 常见问题与排查技巧实录

5.1 Spring Boot 相关经典报错

个人项目里，很多时间其实都花在环境问题上，业务代码反而不是大坑。下面几张表我给的是自己实际遇到过的问题，照着排查基本能解决。

5.2 业务数据上的坑

除开技术报错，业务数据上的坑更难发现，也更致命。我在这里举几个真实案例：

优惠券面额门槛是“满 300 减 50”，但如果用户下单实付 280，加上配送费或清洁费到了 320，这个门槛算不算过？民宿订单往往还有清洁费、押金这些附加费用。我的处理方式是：门槛只按房费总额计算，不把清洁费和押金算进去，这样规则最不容易引起客诉。实现时一定要在代码里把这个口径写死。

积分抵扣和优惠券叠加的顺序怎么定？我在项目里规定先算优惠券抵扣，再用积分抵扣，但两者抵扣后的总额不能超过订单房费本身。如果券和积分都往最低价打，老板的利润就全没了。营销工具虽然叫营销，最终还是要保护收入底线。

房态日期拆分的边界：用户在系统里选入住时间是 8 月 1 日，离店时间是 8 月 3 日，那么 8 月 1 日、8 月 2 日两个晚上都要有库存，8 月 3 日当天不用锁。日期范围如果直接拿离店时间去减入住时间，一定要记住 endDate 本身是不占用房间的。在跨年跨月的订单里尤其容易出错，因为 LocalDate 的 isBefore(endDate) 循环天然过滤掉了最后一个日期，所以我在代码里才专门写了一个 dateRange 工具，注释里也写清楚左闭右开。

5.3 排查工具与调优建议

线上出了问题，不要靠 System.out 和肉眼看日志。我常用的套路是：先打开 MySQL 慢查询日志，找出耗时高的 SQL，再看接口的响应时间。民宿系统最容易出现慢查询的就是房态日历列表页，因为要按日期区间查一整年的价格。这个表建议建联合索引 (room_id, sale_date)，索引一旦建上，价格日历接口从原来的 200ms 降到 10ms 左右是常态。

偶尔内存不足导致进程挂掉，优先检查是不是查询把全表数据都 load 到 JVM 了。比如统计报表时一次性按月份分组没问题，但用 select * 把几万行订单查出来在 Java 内存里求和就是很糟糕的写法。数据库能聚合计算的，不要让 Java 去兜着。

个人开发环境还可以装一个 Arthas，一旦遇到接口卡死或 CPU 飙高，能直接看到是哪个线程在执行什么方法。虽然刚开始用会觉得命令多，但只需要会 dashboard、thread、watch 这几个基础命令，也能解决大部分问题。

6. 项目复盘与后续扩展建议

6.1 如果把这个系统放线上，我会优先改掉哪三个地方

第一是支付回调里的本地事务问题。用户支付成功后，我要在同一事务里改订单状态、加积分、核销优惠券。如果会员系统某一天响应慢了，会导致整个事务迟迟不提交，甚至影响支付结果确认。更合理的做法是支付回调只负责改订单状态，然后发送一个内部事件，积分和优惠券的消费者异步处理。Spring 的 @TransactionalEventListener 可以做到这一点，代码结构也不需要大改。

第二是图片存储。本地磁盘在当前项目里够用，但如果有两家店同时在用，图片都在一台服务器里，一旦服务器磁盘故障全没。如果打算长期经营，可以把 MinIO 的桶迁移到云厂商的对象存储，配合 CDN 加速，成本也不高。民宿房源图片尺寸大、数量多，CDN 对大图的加载速度提升远比后端接口性能优化来得明显。

第三是接口侧加上频控和风控。优惠券领券接口如果被刷，一个人短时间内可以领走几百张面值不小的券。之前我只做了“每个用户限领一张”的 DB 校验，但还是挡不住同一手机号批量注册。后面加了注册时手机验证码 + 同一设备每天注册次数限制，再配合 Redis 对领券接口做单用户每分钟 1 次的频控，问题才算解决。

6.2 从“能用”到“好用”，运营后台还有哪些扩展空间

如果继续往营销方向做，可以增加一套很轻量的人群标签系统。比如根据用户的历史订单，给用户打上“亲子游”“情侣出行”“商旅短住”“复购率高”这样的标签，然后做针对性的营销触达。民宿和酒店不一样，房间的调性差异很大，给亲子游客人推“带滑梯的loft”，比推“极简大床房”效果好得多。

数据报表也值得做深一层：实时看板里除了订单量、销售额，我还会关心各渠道带来的转化率。用户从公众号文章进来、从抖音小程序进来、从好友分享链接进来，都应该能统计到来源。这个“渠道追踪”字段其实在用户第一次落地页生成 token 时就可以埋好，放到成员表里。没有渠道归因，民宿老板就不知道钱该花在哪个平台投流，做营销系统信息价值会少一大块。

小程序端的自动登录、微信支付也是比较容易扩展的方向。当前系统用的是账号密码和手机验证码，而民宿场景里客人到一个地方临时订房，更习惯微信小程序直接授权登录。登录链路变了，但核心的后端订房、支付、房态逻辑其实一套都能兼容。把 JWT 换成微信 session 换取的自定义登录态就行，整个技术架构不用推翻。

最后说个选型上的提醒：不要为了表现技术栈丰富，把 Flowable 这类工作流引擎硬加到民宿系统里。民宿运营流程说到底是订单、库存和营销，不是复杂审批链。我曾经见过一个项目用了 Flowable 去管理“用户下单审批、店长确认订单”流程，实际场景里这种方式反而降低了民宿接单效率。技术选型应该是业务的仆人，而不是项目的装饰品。

这个项目一路做下来，我最大的体会是：营销系统不是功能堆出来的，而是把钱、库存、用户体验三件事理顺了，再叠加一些能刺激客人的活动规则。房态库存表设计得扎实，一万个并发订单也可以从容处理；如果主题模型错了，后面堆再多营销玩法都是在坏地基上盖高楼。如果你正准备做同类的旅游民宿系统，建议先别急着写代码，把“房间—日期—库存—价格—订单”这条线在白板上画明白，再动手。等核心闭环稳定了，再一点点把会员、优惠券、数据分析这些营销能力加进去，你会发现系统会越做越顺手。