露营地预订小程序开发实战

去年夏天我花了一个月时间，从零开发了一款露营地预订小程序。上线三个月后，合作营地从最初的1家扩展到12家，累计完成订单超过800笔。这篇文章把整个开发过程中的技术选型、核心模块设计和踩过的坑整理出来，希望能帮到想做类似项目的朋友。

为什么选择小程序而不是APP

露营地预订这个场景有几个特点：用户决策周期短、使用频率低、强依赖社交分享。这三点几乎完美匹配微信小程序：

• 获客成本低：用户扫码即用，不用下载安装，营地现场放个二维码就能转化
• 分享链路短：微信好友、群聊直接转发小程序卡片，比APP分享链接体验好太多
• 支付闭环成熟：微信支付接入简单，退款流程也有现成方案
• 开发成本可控：一个人用原生小程序框架+云开发，一个月能出MVP

如果你的目标用户主要是年轻露营爱好者，小程序几乎是唯一选择。

核心功能模块拆解

1. 营地展示与筛选

营地列表页需要支持按距离、价格、设施标签筛选。数据结构上，每个营地包含：名称、坐标、图片集、可预订日期、营位类型（帐篷位/房车位/木屋）、价格、设施标签（卫生间/热水/充电/烧烤区）。

距离计算用微信小程序的 wx.getLocation 获取用户坐标，后端用 Haversine 公式算直线距离。如果营地数量超过500个，建议用地理位置索引（MongoDB 的 2dsphere 或 PostgreSQL 的 PostGIS）。

2. 日历库存管理

这是整个系统最复杂的部分。每个营位每天有独立库存，需要处理：

• 用户选择日期范围后，实时查询可用营位
• 下单时锁定库存，15分钟未支付自动释放
• 营地管理员可以批量设置某段时间不可预订

库存表设计建议用 camp_site_id + date 作为唯一索引，每天一条记录，字段包括 total（总库存）、booked（已预订数）、locked（锁定数）。查询可用库存时用 total - booked - locked。

// 库存扣减的原子操作（云开发示例）
const db = cloud.database()
const _ = db.command

async function lockInventory(siteId, date, count) {
  const res = await db.collection('inventory')
    .where({
      site_id: siteId,
      date: date,
      available: _.gte(count)
    })
    .update({
      data: {
        locked: _.inc(count),
        available: _.inc(-count)
      }
    })
  return res.stats.updated > 0
}

注意：一定要用数据库层面的原子操作，不要先查再更新，否则高并发下会超卖。我早期版本就踩过这个坑，国庆期间一个热门营地超卖了3单，最后只能给用户升级房型补偿。

3. 订单与支付

订单状态机要设计清楚：待支付 → 已支付 → 已确认 → 已入住 → 已完成，以及分支状态 已取消 和 已退款。微信支付的回调要幂等处理，防止重复更新订单状态。

退款策略建议按时间阶梯：入住前7天全额退，3-7天退50%，3天内不退。这个规则要在下单页明确展示，避免纠纷。

4. 营地端管理

营地老板通常不擅长用复杂后台，所以我把管理功能也做进了小程序，用角色权限区分。营地端只需要三个功能：查看今日订单、核销入住、调整库存。核销用 wx.scanCode 扫用户订单二维码即可。

技术选型与踩坑记录

• 后端：微信云开发。优点是免运维、自带数据库和云函数，缺点是复杂查询能力弱。如果订单量超过日均500单，建议迁移到自建 Node.js + MySQL。
• 图片存储：云存储+CDN。营地图片多且大，一定要做压缩和懒加载，否则列表页加载慢得离谱。
• 地图：用 map 组件展示营地分布，但注意小程序 map 组件层级很高，会遮挡弹窗，需要用 cover-view 或者把弹窗做成独立页面。
• 日期选择：原生 picker 不支持范围选择，我用的是自己封装的日历组件，支持跨月选择和多日期高亮。

运营层面的思考

技术只是基础，露营地预订的难点在供给端。开发完成后我花了更多时间在：帮营地拍照、录入信息、设置合理的价格日历。小程序本身不产生价值，连接用户和优质营地才有价值。

另外建议早期不要做太复杂的会员体系，先把「找到营地→看详情→选日期→下单→核销」这条主链路跑通，验证有真实订单后再迭代。

如果你也在做类似项目，欢迎交流。后续我会再写一篇关于营地端库存同步和防超卖的具体实现细节。