景区门票小程序开发实战

为什么景区需要自己的门票小程序

过去几年，很多景区依赖OTA平台分销门票，抽成高、用户数据拿不到、高峰期核销还容易堵。自建景区门票小程序，最大的价值在于把流量和交易握在自己手里。用户扫码即用，无需下载App，购票、预约、核销形成闭环，同时还能沉淀会员数据，做二次营销。

本文从一位独立开发者的视角，拆解景区门票小程序的核心模块、技术选型和几个容易踩的坑，文末给出可复用的下单与核销代码思路。

核心功能模块拆解

1. 门票与库存

• 票种管理：成人票、儿童票、老人票、套票、年卡，支持不同价格与适用日期。
• 库存控制：按日期维度设置每日可售数量，避免超卖。
• 分时段预约：热门景区按上午/下午分时段放票，缓解入园压力。

2. 下单与支付

• 选择日期、票种、数量，实时计算价格。
• 调用微信支付，支付成功后异步回调更新订单状态。
• 订单超时未支付自动关闭，释放库存。

3. 核销入园

• 生成动态二维码，游客出示，闸机或工作人员扫码核销。
• 核销记录实时同步，防止一码多用。
• 支持身份证、人脸识别等辅助核验方式。

4. 后台管理

• 订单查询、退款处理、核销统计。
• 票价调整、库存配置、活动配置。
• 数据看板：销量、客流、渠道来源。

技术选型建议

前端用微信小程序原生或Taro，后端可选Node.js、Java、Go。对于独立开发者，我推荐微信云开发或云函数+云数据库，省去服务器运维，快速上线。数据库设计上，订单表、票种表、库存表、核销记录表要分开，避免单表膨胀。

// 云函数：创建订单（简化版）
const cloud = require('wx-server-sdk')
cloud.init()
const db = cloud.database()

exports.main = async (event) => {
  const { ticketId, date, count, openid } = event
  // 1. 校验库存
  const stock = await db.collection('stock')
    .where({ ticketId, date })
    .get()
  if (!stock.data.length || stock.data[0].remain < count) {
    return { code: 400, msg: '库存不足' }
  }
  // 2. 扣减库存（用原子操作防超卖）
  await db.collection('stock')
    .doc(stock.data[0]._id)
    .update({ data: { remain: db.command.inc(-count) } })
  // 3. 创建订单
  const order = await db.collection('orders').add({
    data: {
      ticketId, date, count, openid,
      status: 'pending',
      createTime: Date.now()
    }
  })
  return { code: 0, orderId: order._id }
}

注意库存扣减要用inc原子操作，或者在事务中处理，否则并发下单时容易超卖。微信云开发支持数据库事务，建议在创建订单和扣库存时使用。

核销环节的实现要点

核销是景区门票小程序最容易出问题的地方。常见方案是生成一个带签名和过期时间的二维码，内容包含订单号和核销凭证。工作人员用小程序扫码端调用云函数校验，校验通过后写入核销记录并更新订单状态。

// 核销云函数
const cloud = require('wx-server-sdk')
cloud.init()
const db = cloud.database()

exports.main = async (event) => {
  const { orderId, sign } = event
  // 校验签名，防止伪造二维码
  if (!verifySign(orderId, sign)) {
    return { code: 403, msg: '凭证无效' }
  }
  const order = await db.collection('orders').doc(orderId).get()
  if (order.data.status !== 'paid') {
    return { code: 400, msg: '订单状态异常' }
  }
  // 幂等处理：已核销直接返回
  if (order.data.status === 'used') {
    return { code: 400, msg: '该票已核销' }
  }
  await db.collection('orders').doc(orderId).update({
    data: { status: 'used', useTime: Date.now() }
  })
  return { code: 0, msg: '核销成功' }
}

核销接口一定要做幂等，网络重试或工作人员重复扫码时不能重复核销。另外二维码建议设置较短有效期，比如5分钟，过期后用户在小程序内刷新即可。

几个容易踩的坑

• 退款逻辑复杂：未核销可退、已核销不可退、部分退款，需要提前设计好状态机。
• 库存与订单不一致：支付回调失败或超时关单时，要及时回滚库存。
• 高峰期并发：节假日瞬时下单量大，云函数要设置足够的并发上限，数据库索引要加好。
• 合规问题：涉及在线售票，需具备相关经营资质，小程序类目要选对。

总结

景区门票小程序的技术难度不算高，难点在于库存一致性、核销幂等和退款状态机这三个业务细节。用微信云开发可以快速搭出MVP，先跑通购票核销闭环，再逐步加入会员、营销和数据分析。对于独立开发者来说，这是一个需求明确、可复制性强的项目类型，值得投入时间打磨。