上个月有位做民宿运营的朋友找到我想把手底下分散在景区周边的十几套房源统一管起来同时要支持发优惠券、限时秒杀、会员裂变这些常见的网络营销玩法。我评估了两天最终用SpringBoot Java这套技术栈给他搭了一套旅游民宿网络营销系统。整套系统做下来我最大的感受是民宿预订这类业务真正的难点不在功能多而在房态并发、支付回调、营销库存这三块任何一个环节处理不好上线第一个假期就会出事故。这篇文章我把整个项目的需求拆解、表设计、核心实现和踩坑过程完整写出来给打算用SpringBoot做同类型系统的朋友一个参照。1. 先想明白再动手民宿营销系统的业务本质与技术选型逻辑1.1 民宿和酒店的需求差在哪先说业务判断。很多人一听民宿预订系统下意识就会往酒店管理系统上靠这是第一个认知偏差。民宿和酒店的需求差异非常明显民宿房源非标准化。同一栋楼里可能既有一居室又有三居室有的带院子有的允许带宠物有的只接受整栋包场。房型属性必须做成可配置化的字段不能写死成标间/大床房。房态变化极其频繁。老板可能临时自住、临时下架清洗布草、突然接了一个长租客。系统要能对某套房源按日期单独关房并且允许运营人员在手机上快速操作。价格策略灵活。平日价、节假日价、连住优惠、早鸟价、尾房甩卖会同时存在。价格不适合写死在房型上更适合按日期粒度落在一张房态日历表里。营销属性强。民宿的流量更多来自内容种草、老客带新客所以会员、优惠券、秒杀、分销返佣这些能力不是加分项而是刚需。退改规则不同。有的房源入住前3天可免费退有的节假日订单不可退规则必须挂在房源或房型上。所以我给朋友做的第一件事不是画界面原型而是把需求按房源管理、交易预订、营销活动、内容展示四块重新梳理了一遍。只有把业务边界划清楚后面建表、写接口才不会乱。1.2 为什么是SpringBoot Java我选SpringBoot Java不是因为它最先进而是因为它在这类业务里最不折腾。理由有三个。第一是团队梯队。Java开发者在市场上最容易招到社区资料也最全。对一个要长期迭代的民宿营销系统来说后面接手的人不会因为看不懂技术栈而返工。第二是生态齐全。SpringBoot自带自动配置和起步依赖MyBatis-Plus解决单表CRUDRedis解决缓存和秒杀RocketMQ处理异步消息这些组件在Java生态里都有非常成熟的整合方案踩坑的代价极低。第三是部署简单。一个可执行jar包丢到服务器上就能跑配合Nginx做反向代理运维门槛很低特别适合民宿这种体量的项目。再从另一个角度说这套系统本质上是一个交易系统 营销系统的混合体。交易系统要求可靠营销系统要求快。SpringBoot负责把业务逻辑编排得结构清晰Redis把热点和高并发的部分挡在前面两者各司其职。这也是我在同类项目里反复验证过的最稳妥组合。1.3 SpringBoot版本选2.7还是3.x别被版本太高带偏springboot版本太高这类问题我基本可以断定绝大部分情况不是框架版本高而是本地JDK版本不匹配。SpringBoot 2.7.x最低要求Java 8SpringBoot 3.x必须Java 17。很多人直接创建SpringBoot 3.2项目本地却还是JDK 8一启动就报UnsupportedClassVersionError然后就到处问版本太高怎么办。我给这套民宿系统的建议是团队普遍还是Java 8的底子用SpringBoot 2.7.18最稳如果愿意切Java 17新项目直接上3.2。两者的关键差异我在表格里列一下对比项SpringBoot 2.7.xSpringBoot 3.2最低JDK版本Java 8Java 17包名前缀javax.*jakarta.*MyBatis-Plus兼容性全兼容需3.5.3以上版本Spring Cloud生态对应2021.x/2022.x对应2023.x社区维护状态开源维护期已结束只有商业技术支持渠道持续维护如果只是做一个交付型的中小型系统2.7.x Java 8的组合够用且稳如果是从0启动、没有历史包袱的项目3.2更符合趋势。不要盲目追版本号先把你手里的JDK版本弄清楚再决定框架版本。2. 功能清单与表结构设计把房源、订单、营销的数据边界划清楚2.1 四端功能矩阵按业务角色划分这套系统我拆成四个端来做每个端只关心自己的事避免把所有功能塞进一个后台里最后变成大杂烩。端核心功能我的实现方式用户端H5/小程序民宿列表、详情、在线预订、支付、优惠券领取、评价、会员中心前后端分离Vue/uniapp 后端REST API商户端民宿老板房源维护、房态日历设置、订单接单、入住登记、经营统计Web管理界面平台管理后台用户管理、商户审核、营销活动配置、内容管理、数据看板Web管理界面营销中台服务层优惠券发放、秒杀、拼团、分销返佣、消息通知后端服务 定时任务 MQ这样分完之后用户端对接支付、商户端对接房态、平台端对接营销职责很清晰。实际上开发时商户端和平台后台可以共用一个SpringBoot项目只是用不同菜单权限区分用户端单独提供REST API。前端我选了Vue3 Element Plus小程序用uni-app同一套JS逻辑可以同时编译到H5端和微信小程序端。民宿老板最看重的就是用户在小程序里下单这块绕不过去。2.2 核心表结构与字段设计理由表设计是整个系统的地基尤其是订单、房态、优惠券这三块字段设计错了后面改起来非常痛苦。我直接给出我最终落地的核心表结构并解释几个容易被忽视的设计点。-- 民宿主体表 CREATE TABLE homestay ( id bigint NOT NULL AUTO_INCREMENT, owner_id bigint NOT NULL COMMENT 房东用户ID, name varchar(100) NOT NULL COMMENT 民宿名称, city varchar(50) NOT NULL, address varchar(255) NOT NULL, cover_img varchar(255) DEFAULT NULL, description text, status tinyint NOT NULL DEFAULT 0 COMMENT 0待上架 1上架 2下架, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 房态日历表按日期存房量和价格 CREATE TABLE room_calendar ( id bigint NOT NULL AUTO_INCREMENT, room_type_id bigint NOT NULL, stock_date date NOT NULL COMMENT 日期, total_stock int NOT NULL DEFAULT 1 COMMENT 当日总房量, used_stock int NOT NULL DEFAULT 0 COMMENT 当日已占用量, price decimal(10,2) NOT NULL COMMENT 当日单价, status tinyint NOT NULL DEFAULT 1 COMMENT 1可售 0关房, PRIMARY KEY (id), UNIQUE KEY uk_room_date (room_type_id, stock_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房态日历; -- 订单主表 CREATE TABLE order_info ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, member_id bigint NOT NULL, room_type_id bigint NOT NULL, homestay_id bigint NOT NULL, check_in date NOT NULL, check_out date NOT NULL, nights int NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已入住 3已完成 4已取消 5退款中 6已退款, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_member (member_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个关键设计点提一下。金额字段一律用DECIMAL(10,2)不要用double。这不是洁癖浮点数在金额计算上会有精度问题算错了就是客户投诉甚至资损。订单号要有唯一索引并且由我们自己生成。我用雪花算法生成长整型转字符串不依赖数据库自增ID当作外部订单号。支付回调、对账、客服查单全靠这个号唯一性和可读性都很重要。房态日历表用(room_type_id, stock_date)做唯一索引保证一个房型一天只有一条库存记录这是后面防超卖的前提。优惠券设计我拆成模板表和用户持券表两张coupon_template总量、剩余量、每人限领、使用门槛、有效期和user_coupon用户ID、模板ID、状态、领取时间。拆开的目的是方便统计一个活动发了多少、用了多少、过期多少运营要看这些数据。2.3 表不存在自动建表的开发期方案与生产期反对意见热词里有springboot mybatis 当表不存在自动建表这个点我多说几句。MyBatis-Plus本身没有自动建表能力很多人用的是Spring JPA的spring.jpa.hibernate.ddl-autoupdate或者自定义一个启动监听器执行建表SQL。我平时在项目里是这样处理演示项目、毕设、内网测试环境我认同自动建表方案能省很多事。比如在启动类加一个ApplicationRunner用JdbcTemplate执行CREATE TABLE IF NOT EXISTS脚本里写清楚表结构系统启动时自动补齐缺失的表。Component public class TableInitializer implements ApplicationRunner { Resource private JdbcTemplate jdbcTemplate; Override public void run(ApplicationArguments args) { jdbcTemplate.execute(CREATE TABLE IF NOT EXISTS homestay ( id BIGINT PRIMARY KEY AUTO_INCREMENT, owner_id BIGINT NOT NULL, name VARCHAR(100) NOT NULL, status TINYINT DEFAULT 0 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4); } }但生产环境我强烈建议用Flyway这类数据库版本管理工具。原因很简单自动建表只解决表不存在的问题解决不了表结构要变更的问题。系统上线三个月后要加一个佣金比例字段你总不能让程序启动时去改线上表吧Flyway把每次结构变更定义成一个带版本号的SQL脚本启动时按顺序执行既能追踪历史又能保证测试环境和生产环境的表结构完全一致。这套系统上线后我经历了多次迭代Flyway带来的安心感是自动建表给不了的。3. 房态与订单体系并发场景下最容易翻车的两个核心模块3.1 用数据库原子更新防库存超卖民宿行业的库存和标准酒店不一样标准酒店通常能卖几十上百间但民宿一个房型往往就一两间节假日热门房源同时可能有几十个人在抢。最典型的并发问题就是超卖库存只剩1间却有3个订单都支付成功了。我选择用数据库的原子更新来兜底而不是先查再改。所谓先查再改是指先把used_stock查出来判断小于total_stock再执行UPDATE。这个逻辑在并发下一定会出问题——两个请求同时查到used_stock0同时判断可以卖然后都执行加1结果就超卖了。正确做法是把判断条件写进UPDATE语句里让数据库帮我们做原子校验int rows roomCalendarMapper.update(null, new LambdaUpdateWrapperRoomCalendar() .setSql(used_stock used_stock 1) .eq(RoomCalendar::getRoomTypeId, request.getRoomTypeId()) .eq(RoomCalendar::getStockDate, request.getCheckInDate()) .eq(RoomCalendar::getStatus, 1) .apply(used_stock total_stock)); if (rows 0) { throw new BusinessException(手慢了该日期房源已被订完); }这里的关键是最后一行的.apply(used_stock total_stock)它把还有余房才允许加1这个条件放进了UPDATE的WHERE子句。InnoDB执行UPDATE时会对该行加行锁两个并发请求同时执行时后一个必须等前一个提交执行完后used_stock已经变成1判断1 1不成立更新行数为0直接返回订完。这样就不会超卖。一个注意点这段代码要和订单创建放在同一个事务里。如果库存占用成功了但后面订单插入失败事务回滚会把used_stock也回滚掉不会出现库存扣了但订单没生成的脏数据。我用Transactional(rollbackFor Exception.class)包service方法库存更新和订单插入必须在一起。3.2 支付回调的幂等处理状态条件更新比锁更可靠订单支付这块我接的是微信支付。支付回调有个老生常谈但永远有人踩的坑微信会多次通知同一个支付结果如果你的接口处理不了重复回调用户就会收到两条支付成功的推送订单状态也可能被错误覆盖。我的处理思路是状态条件更新 事务两步走。第一步解析并验签回调报文确认这是微信官方发来的。第二步不先查订单再做判断而是直接执行一条带状态条件的UPDATEint rows orderInfoMapper.update(null, new LambdaUpdateWrapperOrderInfo() .eq(OrderInfo::getOrderNo, orderNo) .eq(OrderInfo::getStatus, OrderStatus.PENDING_PAY.getCode()) .set(OrderInfo::getStatus, OrderStatus.PAID.getCode()) .set(OrderInfo::getPayTime, new Date()) .set(OrderInfo::getTransactionId, transactionId)); if (rows 1) { // 第一次处理该回调更新房间状态、发送入住通知等 mqTemplate.send(order.paid, orderNo); } // rows 0 说明订单状态已经不是待支付属于重复回调直接应答成功这段代码的精髓在于把status 0这个条件放进UPDATE的WHERE条件里。数据库保证同一时刻只有一个回调能把订单从待支付改成已支付其余回调更新行数为0自然就被幂等掉了。这就是我在实际项目中更偏爱条件更新而不是先加分布式锁再改状态的原因少维护一把锁也少一个锁超时带来的复杂分支。当然如果你的回调处理逻辑不只是改订单状态还要同步改房态、发短信、给房东推送消息那就需要消息队列来兜底。先把订单改成已支付再发一条order.paid消息由消费者处理后续副作用消费者自身保证幂等。这样做的好处是回调接口响应非常快微信侧不会因为超时而反复重试。3.3 超时未支付与退款的兜底任务订单状态机里还有一个很容易被忽略的环节用户下了单但不支付。如果一个房型被待支付订单占了库存又一直不释放后面真正想订的人就订不到了。民宿不像酒店有大库存一两间房被占死影响非常直接。我的方案是待支付订单保留15分钟超过时间自动取消并释放库存。实现上有两种主流做法我在这套系统里用的是定时任务扫描Component public class OrderTimeoutJob { Scheduled(cron 0 */1 * * * ?) // 每分钟跑一次 public void cancelExpiredOrders() { // 查出创建时间超过15分钟且状态为待支付的订单 ListOrderInfo expiredOrders orderMapper.selectExpiredPendingOrders(15); for (OrderInfo order : expiredOrders) { cancelOrder(order.getOrderNo()); } } }取消订单时要做的核心动作就两件事把订单状态改成已取消把房态日历上的used_stock减回去。这里也要注意并发如果用户刚好在定时任务执行那一刻点了支付怎么办所以取消动作同样要加状态条件只有status 0的订单才能被取消如果用户已经支付成功更新行数为0取消动作直接跳过。退款链路的处理稍微复杂一点。入住前取消订单、或者房东确认无法接待时需要走退款。退款我单独封装了一个RefundService先查原始支付渠道调用退款接口拿到退款单号再把订单状态从已支付推进到退款中最后等退款结果回调把状态更新为已退款。整个流程宁可慢、不要乱退款这种事一旦重复操作资损和投诉是跑不掉的。4. 营销玩法落地优惠券、限时抢购与内容静态化的实操方案4.1 优惠券从创建到核销的完整链路营销模块里优惠券是最基础也最常用的。我把优惠券的生命周期设计成四个阶段创建、领取、使用、核销。创建阶段在平台后台操作。运营填一个模板满减门槛、优惠金额、发行总量、每人限领、有效期。这些信息落到coupon_template表初始remaining total。领取阶段要注意并发。比如发1000张券实际来领的可能是5000人如果还是先查剩余再insert最后超发的数量会很难看。我用和库存扣减一样的原子更新思路int rows couponTemplateMapper.update(null, new LambdaUpdateWrapperCouponTemplate() .setSql(remaining remaining - 1) .eq(CouponTemplate::getId, templateId) .gt(remaining, 0)); if (rows 0) { return Result.error(手慢了优惠券领完了); } userCouponMapper.insert(buildUserCoupon(template, memberId));同样的模式把remaining 0写进WHERE条件只有减成功的人才能拿到券。这里还有一个细节user_coupon表要加上(user_id, template_id)唯一索引防止同一用户通过并发请求重复领券。使用阶段是在下单时判断。用户提交订单时带上userCouponId后端校验这张券是否属于当前用户、是否在有效期内、订单金额是否满足门槛校验通过后在订单上记录优惠金额。核销阶段在支付成功后执行确认订单已支付然后把券状态改成已使用。如果订单被取消且已使用了券要把券释放回未使用状态同时要保证和房态释放放在同一个事务里。4.2 限时抢购房Redis Lua 顶住瞬时流量民宿做营销最刺激的场景就是节假日前的限量秒杀房。比如端午节放5间特价房出来抢一瞬间可能涌进几千个请求。这种场景还走数据库扣库存等于拿业务主库去扛流量非常不明智。我的做法是把秒杀库存预加载到Redis里用Lua脚本保证原子性-- KEYS[1] 库存keyKEYS[2] 已参与用户key -- ARGV[1] 用户IDARGV[2] 购买数量 local memberId ARGV[1] local qty tonumber(ARGV[2]) if redis.call(SISMEMBER, KEYS[2], memberId) 1 then return -1 end local stock tonumber(redis.call(GET, KEYS[1]) or 0) if stock qty then return 0 end redis.call(DECRBY, KEYS[1], qty) redis.call(SADD, KEYS[2], memberId) return 1Java端调用private static final DefaultRedisScriptLong SECKILL_SCRIPT new DefaultRedisScript(LUA, Long.class); public boolean tryAcquire(Long activityId, Long memberId, int qty) { Long result redisTemplate.execute(SECKILL_SCRIPT, List.of(stock:seckill: activityId, bought:seckill: activityId), memberId.toString(), String.valueOf(qty)); return Long.valueOf(1).equals(result); }为什么一定要用Lua脚本因为秒杀是典型的先检查后扣减逻辑如果拆成两步Java方法调用——先查库存再扣库存——在并发下必然有多个线程同时通过检查造成超发。Lua脚本在Redis里是原子执行的检查库存、扣减、记录用户三步串行完成中间不会有其他命令插进来。拿到扣减成功的结果后我再把创建订单这件事丢进RocketMQ由消费者异步去写订单表。用户在页面上看到抢购成功时订单还没落库但几秒内就会生成。这样做的好处是秒杀接口的TPS上限由Redis决定而不是由数据库连接池决定扛几千QPS没压力。这里要特别提醒一个点Redis里的库存扣了但订单异步创建失败了怎么办我的兜底方案是定时对账任务每隔几分钟对比Redis扣减记录和订单表发现Redis扣了但订单没生成的就回调补偿创建订单确实创建不了的回补库存。秒杀这种高并发场景一定要有最终一致性的思想不要指望每一步都百分之百完美。4.3 民宿详情页静态化把网络营销落到SEO民宿营销系统里营销不能只靠站内活动还要有外部流量入口。民宿的客源很大一部分来自搜索引擎用户搜大理洱海边民宿杭州千岛湖湖景房能不能搜到你决定了你有没有自然流量。SpringBoot项目默认是前后端分离或者动态渲染的HTML搜索引擎对这两种方式的抓取都不算友好。我在这套系统里做了一步很实用的优化民宿详情页静态化。核心思路是民宿的展示页面大部分内容是稳定的没必要每次请求都走动态接口。我定义了一个Thymeleaf模板当民宿上架或信息修改时程序自动生成一个纯静态HTML文件到服务器指定目录public void buildHomestayHtml(Long homestayId) { HomestayDetailVO detail homestayService.buildDetail(homestayId); Context context new Context(); context.setVariable(homestay, detail); context.setVariable(rooms, detail.getRooms()); String html templateEngine.process(homestay_detail, context); FileUtil.writeUtf8String(html, staticDir /homestay/ homestayId .html); }生成后的静态页由Nginx直接托管接口响应速度比动态渲染快一个数量级搜索引擎也能完整抓到页面里的标题、描述、图片。再配合sitemap.xml定时生成和robots.txt放行民宿在搜索引擎的收录效果会明显好于纯动态站点。这里我还想强调一个SEO细节每栋民宿的HTML里title、meta description、meta keywords都要按房源信息动态生成比如大理古城旁一线海景独栋民宿可住6人含早餐而不是全站用一个固定标题。标题和描述是搜索结果的展示入口写得具体、有卖点点击率才会高。5. 配置安全与部署排障私密配置、JDK环境、上传容量三连坑5.1 数据库密码用jasypt加密不要把密钥写进仓库我见过太多项目把数据库密码、Redis密码明文写在application.yml里然后整个仓库推到代码托管平台上。一旦仓库泄露或者被拉取所有数据等于裸奔。民宿系统的订单里有手机号、身份证登记信息这类敏感数据无论如何都不该明文出现在配置里。我用jasypt-spring-boot-starter做配置加密。核心用法只有三步。第一步引入依赖dependency groupIdcom.github.ulisesbocchio/groupId artifactIdjasypt-spring-boot-starter/artifactId version3.0.5/version /dependency第二步用jasypt自带的命令行工具把明文密码加密java -cp jasypt-1.9.3.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI \ inputroot123456 password你的加盐密钥 algorithmPBEWithMD5AndDES第三步yml里使用ENC(密文)spring: datasource: username: ENC(V29rZ4tJq...) password: ENC(AqSx3wY...) jasypt: encryptor: password: ${JASYPT_PASSWORD}注意jasypt加密器自身需要一个password这个password不要写到yml里而是通过环境变量JASYPT_PASSWORD在服务器启动时注入。这样即使配置文件泄露攻击者拿不到环境变量也解不开密文。我在生产环境的启动命令里都是这样写的JASYPT_PASSWORDxxxxxxxx nohup java -jar homestay-web.jar /dev/null 21 5.2 JDK环境变量混乱的完整排查过程这个坑我替大家踩过必须单独讲一次。java环境变量配置java安装教程springboot版本太高这些搜索背后大概率都是同一个问题机器上装了多个JDK环境变量指向错了。我碰到过一个很典型的场景运维给服务器装了JDK 8用来跑老项目后来又装了一个JDK 17准备测新东西。结果新项目的SpringBoot版本是3.2需要Java 17启动时报UnsupportedClassVersionError。第一反应是SpringBoot版本太高实际上SpringBoot根本没错是JVM用的是JDK 8。排查步骤请按这个顺序来java -version # 看当前命中的JDK echo $JAVA_HOME # 看环境变量指向 which java # 看java命令所在路径 mvn -version # 看Maven用的是哪个JDK常见的坑有两个。第一个坑java -version显示正确但mvn -version显示另一个版本。原因是Maven优先读JAVA_HOME而java命令受PATH影响两者指向不同。第二个坑Linux上/usr/bin/java是一个软链接可能指向/etc/alternatives/java而alternatives又可能在系统更新时被改掉。我的处理方式是统一把JAVA_HOME写进/etc/profile或用户的.bashrc并放在PATH最前面export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH改完记得source /etc/profile然后重新敲java -version和mvn -version确认一致。Windows上类似的毛病也很常见系统变量和用户变量都配了JAVA_HOMEPATH里还有C:\Program Files\Common Files\Oracle\Java\javapath这种高优先级路径导致配了半天环境变量没效果。把那个路径从PATH里删掉让%JAVA_HOME%\bin排在前面基本就好了。5.3 民宿图片上传的容量规划与Nginx配合民宿这种业务图片是命根子。详情页要放客厅、卧室、院子、周边环境各种图老板还经常传视频。我第一版用服务器本地存储后来发现一个很重要的问题图片上传不是一个技术问题而是一个容量和带宽问题。SpringBoot默认的上传大小限制是1MB需要改配置spring: servlet: multipart: max-file-size: 20MB max-request-size: 80MB如果前端表单一次性传多张图max-request-size要比单文件上限大我按20MB单文件、一次8张图来配给了80MB的request上限。对于视频我坚持走分片上传每片5MB后端接收后按业务号合并。一次传几百MB的视频对服务器内存和Tomcat线程都是巨大压力分片上传还能做断点续传体验也好得多。Nginx那边也要同步放开否则你后端配了100MBNginx默认client_max_body_size 1m照样把你拦在门外server { listen 80; server_name homestay.example.com; client_max_body_size 80m; 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; } }如果项目流量再大一点我建议把图片和视频从业务服务器里剥出来放到对象存储阿里云OSS或自建的MinIO服务端直接生成上传凭证或预签名URL前端把文件直传对象存储应用服务器完全不经过文件流的搬运。这套系统上线半年后我统计了一下图片占用的磁盘发现本地存储方案明显扛不住长期运营后来就把图片迁到了对象存储。这是我特别后悔没有一开始就做对的一件事。6. 如果让我重做一遍我会调整这几件事整套系统从需求梳理到上线前后差不多四个月。做完之后复盘有几件事如果重来我会在一开始就做不同选择。第一图片和文件存储绝不用本地磁盘起步。当时想着省事先用本地目录存结果后期迁移对象存储时几十个G的图片要搬数据库里的URL全要改最麻烦的是新老地址兼容。早点用对象存储加预签名URL后面完全不用折腾。第二秒杀场景要提前和运营确认真实并发量。这个项目的秒杀活动是我做的Redis Lua方案扛压完全没问题但运营实际放出来的房源就5间并发峰值几百QPS数据库本身也扛得住。不是说方案不该做而是应该先问清楚量级把精力放在真正有风险的地方比如支付回调幂等和库存一致性这俩才是系统天天要走的路径。第三权限模型要从一开始就设计成多租户。我第一版把商户端和平台端混在一个用户体系里后期加民宿老板的只看自己的房源逻辑时改了非常多接口。如果一开始就引入owner_id隔离和简单的租户概念这里能省一半改动量。第四接口返回结构从第一天起就要统一。我在项目里定义了一个ResultT包含code、message、data三个字段后来所有接口都复用。这个看起来是很小的事但前后端联调时非常省心前端拦截器只需要解析一次错误码比如401跳登录、500弹错误提示。如果一开始各写各的返回结构联调阶段会非常痛苦。最后说一句掏心窝的话做这类中型业务系统最重要的能力不是会用几个框架而是能把业务的风险点找出来。民宿营销系统里房态、支付、营销库存是三个最危险的角落把这三个角落的并发和幂等处理好系统就稳了一大半。剩下的功能再多都是在一个稳定的地基上垒砖而已。