简介这是一份面向微信小程序初学者与进阶开发者的电影购票小程序源码包适合用来练习页面布局、业务逻辑、微信 API 调用与第三方票务接口对接。项目围绕影院排期、影片信息、座位选择、在线支付和订单状态同步等购票主流程展开同时包含外卖示例模块便于理解附加服务与主业务的集成方式。源码包共 92 个文件以 33 个 jpg、16 个 png 图片资源和 14 个 js、10 个 wxml、10 个 wxss、7 个 json 配置与逻辑文件为主压缩包约 394KB结构紧凑方便按页面、组件与工具模块查阅。已有 6446 人学习读者可从中梳理小程序目录组织、WXML/WXSS 页面实现、JavaScript 数据处理及登录支付等接口调用思路并参考示例代码扩展外卖等周边功能积累实际项目的问题排查与功能拆解经验。1. 电影购票小程序能解决什么从选片到出票的一条完整交易链路周三下午接的需求给本地一家影院做微信小程序能选片、选座、下单两周上线影院还得自己能排片。这份电影购票小程序源码就是从这个场景长出来的——前端是小程序页面负责渲染和选座交互后端用云函数加云数据库承接影片、场次、座位、订单四类数据把「选片 → 选场 → 选座 → 锁座 → 支付 → 出票核销」整条链路串成了一条闭环。任何一环掉链子用户就会在选座页直接退出所以它的价值不在于页面多好看而在于这条链路的每个状态都被落库、都能追溯。它适合改成本地影院票务、校园影厅、点播厅预约这类单店或小连锁体量的项目不适合想直接对标全国出票平台的人渠道对接和资质那一层它没有。下面按结构、主链路、运营侧、踩坑、改造的顺序拆。2. 工程结构与技术栈小程序端、云函数、数据库三层怎么分工2.1 目录结构逐个文件说清楚拿到源码先别急着编译把目录过一遍心里就有数了。这个项目的分层很清楚miniprogram/是前端cloudfunctions/是后端两边靠wx.cloud.callFunction通信没有中间层。. ├── miniprogram/ # 小程序端 │ ├── app.js # 云开发初始化、全局登录态 │ ├── app.json # 页面路由、tabBar、窗口配置 │ ├── app.wxss # 全局样式变量主色、间距、字号 │ ├── pages/ │ │ ├── index/ # 首页正在热映 / 即将上映 │ │ ├── movie-detail/ # 影片详情 日期场次选择 │ │ ├── seat/ # 选座页座位矩阵渲染 │ │ ├── order-confirm/ # 订单确认、优惠、发起支付 │ │ ├── order-list/ # 我的订单待支付 / 已支付 / 已使用 │ │ └── ticket/ # 取票码页展示二维码和核销状态 │ ├── components/ │ │ ├── movie-card/ # 影片卡片纯展示 │ │ ├── seat-map/ # 座位矩阵组件只管画不管逻辑 │ │ └── date-tabs/ # 横向日期选择条 │ ├── utils/ │ │ ├── request.js # callFunction 的统一封装 错误码处理 │ │ ├── format.js # 价格分转元、日期格式化 │ │ └── seat.js # 座位矩阵生成与可选状态计算 │ └── images/ # 海报占位图、图标 └── cloudfunctions/ # 云函数后端 ├── getMovies/ # 查影片列表 ├── getSchedules/ # 按影片 日期查场次 ├── getSeatMap/ # 按场次查座位快照 ├── createOrder/ # 校验座位、锁座、写订单事务 ├── payCallback/ # 支付回调改订单状态 ├── cancelOrder/ # 取消订单释放座位 └── verifyTicket/ # 核销取票码看这个结构能读出几个设计取向。第一pages/seat和components/seat-map是分开的选座的计算逻辑集中在utils/seat.js里组件只负责接收矩阵和回调点击事件。这个拆法在选座页很好用——座位表动辄两三百个格子setData一次全量传会很卡拆开之后可以只更新变化的那一行。第二云函数是按「一个动作一个函数」切的不是按表切的。createOrder里同时操作座位和订单cancelOrder里同时改订单和座位边界跟着业务动作走而不是跟着数据表走。常见做法里也有人把所有逻辑塞进一个api云函数用event.action分发好处是冷启动只启一次坏处是函数体积大、权限不好收口。这个项目选了前者我一般也更倾向这种排查时一眼能定位是哪个函数出的问题。第三没有models/之类的抽象层。云函数里直接db.collection(orders).add(...)。对几百行的项目来说这不算问题但二次开发时要注意一旦你开始加多影院、加会员同一张表的写入会散落在四五个云函数里改字段容易漏那时候该抽就抽。启动前要改的地方只有两处app.js里的wx.cloud.init({ env: 你的环境ID })以及云函数目录下每个函数config.json里绑定的环境。这两个地方不一致最典型的后果是真机白屏后面第 5 章会专门讲。2.2 技术选型原生小程序 云开发为什么适合这类项目前端用的是原生小程序WXML / WXSS / JS没有上 uni-app 或 Taro。这不是保守是选座页逼出来的座位矩阵是个几十行乘几十列的网格每次点选都要重算一次可选状态还要做最多 4 张票的联动限制跨端框架多一层编译和 diff输入延迟就出来了。原生setData的路径更新比如this.setData({ matrix[3][5].status: 2 })在这种高频局部更新场景下最省事。后端用云函数 云数据库理由更实际。这个体量的项目单影院日均几十到几百单如果自建 Node 服务服务器、证书、域名、日志、备份这些运维事项的价值远超代码本身而小团队根本没有这个人。云开发把这一层抹掉了db.collection(orders).add()就是写库cloud.getWXContext().OPENID直接拿到用户身份不用自己搞登录态和 token 校验。代价也要说清楚事务能力有限。云开发的事务只能对单个文档做doc(id).get()/update()/remove()不支持在事务里where查询。这一点直接决定了createOrder的写法第 3 章会展开。云函数有并发和超时上限默认超时比较短座位多的时候循环更新很容易打满。聚合查询有结果条数限制做统计页时要注意分页或者分批。一句话总结选型单店体量、想快上线、没有运维走云开发日单过万或者要做多租户 SaaS趁早迁到自建服务。这也是我判断一份购票源码值不值得接手的第一个标准——它的数据访问是不是集中在云函数里如果是迁起来工作量可控如果散在页面里到处直连数据库那就很难受。2.3 数据模型影片、场次、座位、订单四张表怎么设计云数据库没有 schema全靠约定。这四个集合的字段约定建议先抄下来后面改代码全靠它对照。集合关键字段说明movies_id、title、poster、duration、rating、status、releaseDatestatus取ON/OFF下架不删数据schedules_id、movieId、hallName、showDate、startTime、price、cinemaIdshowDate存YYYY-MM-DD字符串startTime存HH:mmseats_id、scheduleId、row、col、type、status、lockTime、lockBystatus0 可售 / 1 已售 / 2 锁定 / 3 维修orders_id、openid、scheduleId、seatIds、totalPrice、status、outTradeNo、transactionId、createdAt、paidAtstatusPENDING/PAID/CANCELLED/USED两个设计点值得展开。一是seats是按场次快照存的不是按影厅模板实时算。也就是说排片的时候会往seats里插一批带scheduleId的文档一场一百个座位就一百条记录。看着冗余但好处很硬某场次椅子坏了可以直接把那条改成status: 3不影响别的场次影厅后来改了座位布局旧订单里的seatIds还能反查到「当时是 5 排 8 座」。如果用影厅模板实时算这两件事都要额外写兼容逻辑。二是价格用整数分存储。price: 4500表示 45 元前端用utils/format.js里的fen2yuan转成45.00再渲染。浮点数在订单金额上迟早出问题这种钱相关的字段统一用最小单位存是我接手任何交易类项目都要先确认的一件事。索引方面云数据库需要手动建。按查询频率至少给schedules建movieId showDate的复合索引给seats建scheduleId status给orders建openid createdAt降序和outTradeNo的唯一索引。最后这个尤其重要它是支付回调幂等的第一道防线第 3 章会讲。3. 核心购票链路选片、选场、选座、下单、支付怎么串起来3.1 场次渲染一次请求把整页数据拿回来影片详情页要做的事只有一件用户点开某部片子看到未来七天的场次点某一场进选座。这里的坑在于请求次数——如果先查日期、再按日期查场次、再按场次查影厅一个页面就是三次往返弱网下体验很差。源码的做法是一次性把整个影片的场次捞回来前端做分组。云函数大致长这样// cloudfunctions/getSchedules/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const _ db.command exports.main async (event) { const { movieId, days 7 } event if (!movieId) return { code: 4001, msg: 缺少 movieId } // 用字符串比较日期避免 Date 对象在不同环境下的时区偏移 const today new Date() const start formatDate(today) const end formatDate(new Date(today.getTime() days * 86400000)) const res await db.collection(schedules) .where({ movieId, showDate: _.gte(start).and(_.lte(end)), // 只取还没开场的场次已过场的直接不返回 status: ON }) .orderBy(showDate, asc) .orderBy(startTime, asc) .limit(200) .get() // 按日期分组前端拿到直接渲染日期条 const grouped {} res.data.forEach((item) { if (!grouped[item.showDate]) grouped[item.showDate] [] grouped[item.showDate].push(item) }) return { code: 0, data: grouped } } function formatDate(d) { const p (n) (n 10 ? 0 n : n) return ${d.getFullYear()}-${p(d.getMonth() 1)}-${p(d.getDate())} }几个参数的含义说一下。movieId是必传的没有就直接返回错误码别让它进数据库查询。days默认 7 天影院的排片一般也就排一周多的排了也没人看。返回结构是{ 日期: [场次数组] }前端用Object.keys(grouped)拿到日期列表渲染date-tabs选中日期再取对应数组。formatDate这里刻意没有用toISOString().slice(0, 10)。那玩意返回的是 UTC 日期在东八区晚上 8 点之后算出来的「今天」会比本地日期早一天于是当晚新建的场次第二天消失。这个坑我在两个项目里都见过属于典型的「本地测试永远正常、上线当晚就翻车」后面第 5 章还会单独列出来。limit(200)是个保险值。云数据库单次查询有条数上限超过会截断但不报错。一场影院一周的场次不会超过这个数但如果哪天有人加了多影厅批量排片这里就要改成游标分页否则用户会莫名其妙看不到后几天的场次。3.2 选座页的座位矩阵与状态机选座是整个项目最值得看的一页。后端返回的是一维座位数组每条带row和col前端要先还原成二维矩阵才能按行列渲染。// utils/seat.js /** * 把一维座位数组还原成 rows × cols 的矩阵 * param {Array} seats 后端返回的座位数组row/col 从 1 开始 * param {number} rows 总行数 * param {number} cols 总列数 * returns {ArrayArray} 二维数组无座位的格子为 null用于过道留白 */ function buildMatrix(seats, rows, cols) { const matrix [] for (let r 0; r rows; r) { matrix[r] new Array(cols).fill(null) } seats.forEach((seat) { // row/col 是 1 基转成 0 基下标 const r seat.row - 1 const c seat.col - 1 if (r 0 r rows c 0 c cols) { matrix[r][c] seat } }) return matrix } /** * 判断某个座位当前能否被点击 * param {Object|null} seat 座位对象null 表示这格是空的 * param {Array} selected 已选座位 id 列表 * param {number} maxCount 单笔最多选几张 */ function canSelect(seat, selected, maxCount 4) { if (!seat) return false // 空格子过道 if (seat.status ! 0) return false // 已售 / 已锁 / 维修 if (seat.type aisle) return false // 过道位不参与售卖 // 已经选中过的永远允许反选 if (selected.indexOf(seat._id) -1) return true return selected.length maxCount } module.exports { buildMatrix, canSelect }buildMatrix里那个new Array(cols).fill(null)是关键。有些写法直接用seats里的最大col当列数遇到最后一排只有一半座位影院常见的错位布局就会左边整体偏移选座图和实际影厅对不上。用固定rows和cols填null渲染时null的格子输出一个空白占位视觉上才对。页面里的点击逻辑保持得很薄// pages/seat/seat.js 片段 const { canSelect } require(../../utils/seat) Page({ data: { matrix: [], selected: [], maxCount: 4, totalPrice: 0 }, onSeatTap(e) { const { row, col } e.currentTarget.dataset const seat this.data.matrix[row][col] if (!canSelect(seat, this.data.selected, this.data.maxCount)) { if (seat seat.status ! 0) { wx.showToast({ title: 该座位已售出, icon: none }) } else if (this.data.selected.length this.data.maxCount) { wx.showToast({ title: 最多选${this.data.maxCount}张, icon: none }) } return } // 只更新变化的那一格避免整个矩阵重绘 const nextStatus this.data.selected.indexOf(seat._id) -1 ? 0 : 4 this.setData({ [matrix[${row}][${col}].status]: nextStatus, selected: this.toggleId(seat._id) }) this.calcPrice() } })这里用status: 4表示「本地已选中」和数据库里的 0/1/2/3 分开放避免本地选中状态和真实售出状态混在一起——这个区分很重要因为取消选中要还原成 0如果混用用户反选一次座位就变成「已售」只能刷新页面。setData用路径更新matrix[row][col].status而不是整个矩阵重传是这一页能不能跑顺的分水岭。一个 15 行 20 列的影厅有 300 个格子每次点击都全量传中低端机上的点击反馈会明显拖手。还有一处常见做法值得提maxCount不要硬编码在页面里。改成从schedules里读一个maxPerOrder字段运营想临时限制「每单最多 2 张」做活动改数据就行不用发版。选座页的最终产出是selected数组和一个总价点「确认选座」带着scheduleId seatIds跳到订单确认页。注意这时候还没有锁座座位在数据库里仍然是 0。真正的占用发生在下一步。3.3 下单事务与支付回调的幂等处理这是整个项目最容易出问题的地方也是最值得逐行看的地方。createOrder要保证三件事原子完成校验座位可用、把座位改成锁定、写订单。任何一步失败都要整体回滚否则会出现「座位锁了但没订单」或者「订单写了但座位没锁」这种对不上账的状态。// cloudfunctions/createOrder/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { const { OPENID } cloud.getWXContext() const { scheduleId, seatIds } event // 入口校验脏数据不要进事务 if (!scheduleId || !Array.isArray(seatIds) || seatIds.length 0) { return { code: 4001, msg: 参数不完整 } } const transaction await db.startTransaction() try { // 1. 逐条校验座位状态。云开发事务不支持 where 查询 // 只能按 doc 一个个来这是硬限制 let totalPrice 0 for (const id of seatIds) { const seatDoc await transaction.collection(seats).doc(id).get() const seat seatDoc.data if (!seat || seat.scheduleId ! scheduleId) { await transaction.rollback() return { code: 4002, msg: 座位不存在 } } if (seat.status ! 0) { await transaction.rollback() return { code: 4003, msg: 座位已被占用请重新选择 } } totalPrice seat.price || 0 } // 2. 锁座状态改成 2记录锁定人和锁定时间 for (const id of seatIds) { await transaction.collection(seats).doc(id).update({ data: { status: 2, lockBy: OPENID, lockTime: Date.now() } }) } // 3. 写订单状态 PENDING const orderRes await transaction.collection(orders).add({ data: { openid: OPENID, scheduleId, seatIds, totalPrice, status: PENDING, outTradeNo: ${Date.now()}${Math.floor(Math.random() * 10000)}, createdAt: Date.now() } }) await transaction.commit() return { code: 0, data: { orderId: orderRes._id, totalPrice } } } catch (err) { await transaction.rollback() return { code: 500, msg: err.message } } }参数说明scheduleId用来做二次校验防止有人拿 A 场次的座位 id 去下 B 场次的单seatIds是数组长度和maxCount对应totalPrice由服务端从座位价格累加算出来绝对不能用前端传过来的金额——这是收钱的地方前端传什么都不能信。outTradeNo的生成方式比较朴素时间戳加四位随机。单店体量够用但如果你打算做多影院建议换成影院ID 时间戳 自增序列否则同一毫秒两个用户下单有小概率撞号而outTradeNo一旦撞号支付回调查到的订单就是错的。事务里那个for循环是最慢的一段。20 个座位就是 20 次get加 20 次update加上事务本身的开销云函数默认超时很容易打穿。补救办法有两个一是把config.json里的超时时间调大二是把座位数限制在合理范围一单最多 4 到 6 张。常见做法是限制一单座位数业务上也说得通——谁买电影票一次买二十张。支付回调这一侧核心是幂等// cloudfunctions/payCallback/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { // 回调里带回来的商户订单号 const { outTradeNo, transactionId, returnCode } event // 支付失败的通知也要正常应答否则平台会一直重推 if (returnCode ! SUCCESS) return { errcode: 0, errmsg: ok } try { // 幂等的关键条件更新。只有 PENDING 的订单才允许改成 PAID const updateRes await db.collection(orders) .where({ outTradeNo, status: PENDING }) .update({ data: { status: PAID, transactionId, paidAt: Date.now() } }) // updated 为 0 说明这单已经被处理过了或者根本不存在 // 不管哪种情况都返回成功让回调停止重推 if (updateRes.stats.updated 0) { return { errcode: 0, errmsg: ok } } // 座位状态从「锁定」转「已售」 const orderRes await db.collection(orders).where({ outTradeNo }).get() const order orderRes.data[0] for (const id of order.seatIds) { await db.collection(seats).doc(id).update({ data: { status: 1 } }) } return { errcode: 0, errmsg: ok } } catch (err) { // 抛错让平台重推但重推可能造成重复处理 // 所以前面的条件更新必须扛得住 return { errcode: -1, errmsg: err.message } } }逻辑上的重点在于where({ outTradeNo, status: PENDING })。它把「查」和「判断状态」合并成了原子的一步并发进来两次回调只有一次能把updated变成 1另一次拿到 0 直接返回成功。这比「先 get 判断 status 再 update」安全得多后者在两次回调间隔极短时两边都能通过判断。后面的座位转「已售」放在订单更新之后即使这一步中途失败订单已经是PAID了用户能看到票座位状态可以靠定时任务补偿。反过来先改座位再改订单一旦订单更新失败座位就永远卡在「已售」但没人买只能人工修数据。钱的优先级永远高于库存这个顺序不能反。4. 后台与运营侧影片上架、场次排期、订单核销怎么做4.1 影片与场次管理写入约定和校验购票小程序的另一半是运营能力影院自己得能上片、排片。源码里这块没做成独立的 Web 后台而是塞在小程序里的一个隐藏运营页通过openid白名单判定身份——好处是不用再搭一套登录体系坏处是运营人员得在手机上排片体验一般。二次开发时如果影院的排片频率高建议单独做 H5 后台复用同一批云函数就行。排片写入的约定比代码更重要上片时movies只写元信息status默认OFF检查海报和时长无误后再改ON。直接ON的话首页会立刻出现一张没有海报的破图。排片时按movieId hallName showDate startTime做唯一性校验同厅同时间不能排两场。这个校验必须在云函数里做前端算不出来。排片成功后同步生成座位快照。生成逻辑要幂等如果该场次的seats已存在就跳过不要重复插。重复插的后果是同一个座位出现两条记录一条可售一条已售用户点了没反应。座位快照的生成代码大概是这个形状// cloudfunctions/createSchedule/index.js 片段 const ROWS 10 const COLS 16 const AISLE_COLS [4, 13] // 第 4、13 列为过道 async function generateSeats(scheduleId, hallName, basePrice) { const tasks [] for (let r 1; r ROWS; r) { for (let c 1; c COLS; c) { const isAisle AISLE_COLS.indexOf(c) -1 tasks.push({ scheduleId, hallName, row: r, col: c, type: isAisle ? aisle : normal, // 过道位不售卖直接标记为维修态避免被误选 status: isAisle ? 3 : 0, price: basePrice }) } } // 云数据库单次 add 只支持一条批量要用循环或者导入 for (const seat of tasks) { await db.collection(seats).add({ data: seat }) } }160 个座位就是 160 次add这必然超时。实际做法一般是先把座位数据导成 JSON 文件放云存储再用云函数批量导入或者干脆把整个座位矩阵以数组形式存成一条文档牺牲了单座位更新的便利换排片速度。这两种取舍没有绝对对错看你的影院是排片多还是改座多。排片频率高就选数组存储单座维修操作多就选一条一记录。过道位标记成status: 3而不是留空是因为渲染时前端只判断status ! 0就置灰逻辑统一不用在选座页再写一遍type aisle的分支。少一个分支就少一处可能写错的地方。4.2 订单核销与取票码验票端十秒能落地用户付完钱进pages/ticket看到的是一个取票码。这里最简单的实现是把orderId直接编码进二维码验票端扫码后调verifyTicket云函数// cloudfunctions/verifyTicket/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { const { orderId, staffOpenid } event // 只有 PAID 才能核销USED 是重复扫PENDING 是没付钱 const res await db.collection(orders) .where({ _id: orderId, status: PAID }) .update({ data: { status: USED, usedAt: Date.now(), usedBy: staffOpenid } }) if (res.stats.updated 0) { const orderRes await db.collection(orders).doc(orderId).get() const status orderRes.data orderRes.data.status if (status USED) return { code: 4001, msg: 该票已核销 } if (status PENDING) return { code: 4002, msg: 订单未支付 } return { code: 4003, msg: 无效票券 } } return { code: 0, msg: 核销成功 } }和支付回调一个套路条件更新 stats.updated判断。验票口是最不能出并发问题的地方两个检票员同时扫同一张票必须只有一个放行。usedBy记下操作人事后有争议能追溯。取票码本身建议加个短期签名别直接暴露orderId。源码里是明文改造成本不高云函数返回码值时用orderId 时间戳算个哈希拼进去验票时再校验一次时效超过 24 小时自动失效。这一步不做也不算致命但做过的人都知道明文 id 被截图转发给朋友蹭票是迟早的事。4.3 运营侧统计页的聚合查询运营页最后一块是「今天卖了多少」。这块用云数据库的聚合能力做// cloudfunctions/stats/index.js 片段 const db cloud.database() const $ db.command.aggregate exports.main async (event) { const { date } event // YYYY-MM-DD const start new Date(${date}T00:00:0008:00).getTime() const end start 86400000 const res await db.collection(orders) .aggregate() .match({ status: _.in([PAID, USED]), paidAt: _.gte(start).lt(end) }) .group({ _id: null, orderCount: $.sum(1), ticketCount: $.sum($.size($seatIds)), revenue: $.sum($totalPrice) }) .end() return { code: 0, data: res.list[0] || { orderCount: 0, ticketCount: 0, revenue: 0 } } }$.size($seatIds)是统计票数的关键比orderCount更贴近实际——一单买三张票对影院来说卖的是三张。revenue求和出来是分返回值别忘了在前端除 100。聚合查询有结果集上限日订单上千之后match完再group可能被截断。缓解办法是按小时分段查询再累加或者单独维护一张每日汇总表订单支付成功时顺手inc一次。我一般会选后者统计页要求的是快不是绝对实时。5. 避坑与排查座位锁不住、回调重复、真机白屏这几处最容易翻车5.1 两个人同时选到同一个座位现象压测时用两个账号同时点同一场的同一个座位两边都跳到了订单确认页最后两边都能进支付。付款后其中一个订单显示「已支付」但没有取票码另一个订单的座位状态是「已售」。原因前端选座只是本地状态真正的占用在后端。如果createOrder里是「先where查一遍 status 为 0 的座位再循环 update」两个请求可能都查到了「可用」然后都执行了 update。或者更隐蔽的一种事务里用了where查询——云开发事务根本不支持这个代码跑了但没生效等于没校验。解决事务内改成doc(id).get()逐条校验或者在非事务方案里用条件更新where({ _id: id, status: 0 }).update(...)然后检查stats.updated 1抢不到就整体回滚并返回明确的错误码前端收到 4003 就提示「座位已被占用」并刷新座位图。压测脚本我一般会写一个 20 并发的版本跑通才敢上线。5.2 支付成功但订单一直挂着「待支付」现象用户付款成功微信里也收到了扣款通知但小程序订单列表还是「待支付」点进去提示「请尽快完成支付」。客服只能手动退款。原因三种可能。一是回调函数抛异常了平台重推几次后放弃二是回调返回结构不对平台认为没收到应答一直重推三是回调里「先 get 判断 PENDING 再 update」重推时第一次已经改过状态第二次判断不通过直接 return 了但如果第一次改完订单、改座位那步挂了状态就是半拉子。解决回调改成条件更新updated 0一律返回成功返回结构严格按平台要求写别自己加字段再加一个每 5 分钟跑的定时任务做补偿扫描status: PENDING且createdAt超过 10 分钟、但支付侧能查到transactionId的订单直接改成PAID。补偿任务比事后手工退款省事得多。5.3 开发者工具正常真机扫码白屏现象模拟器里点哪哪正常真机预览进去一片白也没报错或者只有一行「云开发未初始化」。原因九成是环境 ID 对不上。app.js里wx.cloud.init({ env })写死了开发环境而真机走的是体验版云开发环境没绑到同一个 AppID 下或者云函数目录里每个函数的config.json各自写了一个环境有一个写错就整个链路断。剩下的一成是图片域名没配、或者用了只有开发者工具才有的 API。解决环境 ID 收到一个config.js里统一管理用wx.getAccountInfoSync().miniProgram.envVersion区分 develop / trial / release 三个环境真机上用小程序自带的调试面板看wx.cloud.callFunction的实际报错上线前把云开发环境和 AppID 的绑定关系在后台确认一遍这一步没确认其它排查都是白费。5.4 场次日期整体错一天现象晚上八点之后新排的场次第二天在列表里找不到或者明明排的是 15 号用户看到的却是 14 号。原因new Date()存进数据库变成 UTC 时间取出来格式化时又按本地时区算了一遍两头不一致。八点这个时间点是因为东八区偏移 8 小时晚上八点之后 UTC 已经是第二天了。解决日期统一存YYYY-MM-DD字符串时间统一存HH:mm字符串只在需要排序和判断是否过期时才转成时间戳而且转换函数只写一份放在utils/format.js。这条规矩定下来之后时区问题基本绝迹。5.5 点「去支付」转圈十几秒然后失败现象选完座点确认按钮转圈十几秒后弹「网络异常请重试」重试还是失败。原因createOrder里循环查座位加循环更新座位一多就超过云函数默认超时。云开发默认超时时间不长事务本身还有额外开销两个叠加直接打穿。解决一是把单笔订单座位数限制在 6 张以内业务上完全说得通二是在云函数的config.json里把timeout调高三是把校验和更新合并非关键动作写日志、发订阅消息拆到另一个云函数异步做。三条一起上正常单笔下单能压到 1 秒内。6. 二次开发从单影院改造到多影院 会员体系的落地思路接这类源码的人十个里有八个最后都要做两件事扩成多影院、加会员。这两件事的改造路径其实不一样别一起动。多影院改造是数据结构改造所有业务表加cinemaId字段schedules、seats、orders、movies如果各店片源不同全加所有云函数入参补cinemaId索引全部重建把cinemaId放到复合索引第一位前端加一个影院选择组件选中的影院存进app.globalDatarequest.js里统一带上。改动点多但机械一天能做完。唯一要想清楚的是首页逻辑是进来先选影院还是按定位推荐最近一家前者实现简单后者要接位置授权还涉及用户拒绝授权后的降级建议一期先做前者。会员体系是业务逻辑改造风险高得多。加一个users集合存openid、手机号、积分、等级订单确认页在算价时插入一层会员折扣支付成功后异步加积分退票时扣回。这里最容易出错的是「折扣和积分叠加算错」因为金额一旦算错就是真金白银。我的做法是永远在云函数里算最终价前端只负责展示和传usePoints: true/false这种开关绝不让前端传折扣后金额。改造顺序和验证方法我一般这么排阶段改动内容验证方式第一步加cinemaId不动业务逻辑用两家影院的测试数据跑完整购票流程确认数据不串第二步前端加影院切换切店后场次、座位、订单列表全部跟着变购物车清空第三步加users集合和积分字段老用户首次进入自动建档不阻塞购票第四步订单算价接入会员折扣用手工算的期望金额逐单比对含 0.01 元边界值第五步压测并发下单20 并发抢同一座位只能成功一单第三步有个细节值得单独说老用户第一次进新版本时并没有users记录如果建档逻辑放在下单流程里一旦建档失败整个下单就挂了。我一般放在app.js的onLaunch里异步做失败了也不影响主流程下次进来再补。这种「非核心链路不阻塞核心链路」的判断是改别人源码时最该先建立的习惯。最后一个技巧关于怎么快速确认一份购票源码靠不靠谱别看页面先搜三个东西——搜setData看看有没有全量更新大数组的搜startTransaction看看事务里有没有where搜outTradeNo看看回调是不是条件更新。这三处只要有一处写错这个项目就一定在某个时段出过对不上账的事故。我从被一次并发锁座事故坑掉一个周末之后每次拿到交易类源码都先跑一遍这三项检查再决定是接着改还是重写。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 3:44:07 · 阅读 1.2k 微信小程序云开发电影购票系统源码：选座锁座与支付回调幂等实践
简介这是一份面向微信小程序初学者与进阶开发者的电影购票小程序源码包适合用来练习页面布局、业务逻辑、微信 API 调用与第三方票务接口对接。项目围绕影院排期、影片信息、座位选择、在线支付和订单状态同步等购票主流程展开同时包含外卖示例模块便于理解附加服务与主业务的集成方式。源码包共 92 个文件以 33 个 jpg、16 个 png 图片资源和 14 个 js、10 个 wxml、10 个 wxss、7 个 json 配置与逻辑文件为主压缩包约 394KB结构紧凑方便按页面、组件与工具模块查阅。已有 6446 人学习读者可从中梳理小程序目录组织、WXML/WXSS 页面实现、JavaScript 数据处理及登录支付等接口调用思路并参考示例代码扩展外卖等周边功能积累实际项目的问题排查与功能拆解经验。1. 电影购票小程序能解决什么从选片到出票的一条完整交易链路周三下午接的需求给本地一家影院做微信小程序能选片、选座、下单两周上线影院还得自己能排片。这份电影购票小程序源码就是从这个场景长出来的——前端是小程序页面负责渲染和选座交互后端用云函数加云数据库承接影片、场次、座位、订单四类数据把「选片 → 选场 → 选座 → 锁座 → 支付 → 出票核销」整条链路串成了一条闭环。任何一环掉链子用户就会在选座页直接退出所以它的价值不在于页面多好看而在于这条链路的每个状态都被落库、都能追溯。它适合改成本地影院票务、校园影厅、点播厅预约这类单店或小连锁体量的项目不适合想直接对标全国出票平台的人渠道对接和资质那一层它没有。下面按结构、主链路、运营侧、踩坑、改造的顺序拆。2. 工程结构与技术栈小程序端、云函数、数据库三层怎么分工2.1 目录结构逐个文件说清楚拿到源码先别急着编译把目录过一遍心里就有数了。这个项目的分层很清楚miniprogram/是前端cloudfunctions/是后端两边靠wx.cloud.callFunction通信没有中间层。. ├── miniprogram/ # 小程序端 │ ├── app.js # 云开发初始化、全局登录态 │ ├── app.json # 页面路由、tabBar、窗口配置 │ ├── app.wxss # 全局样式变量主色、间距、字号 │ ├── pages/ │ │ ├── index/ # 首页正在热映 / 即将上映 │ │ ├── movie-detail/ # 影片详情 日期场次选择 │ │ ├── seat/ # 选座页座位矩阵渲染 │ │ ├── order-confirm/ # 订单确认、优惠、发起支付 │ │ ├── order-list/ # 我的订单待支付 / 已支付 / 已使用 │ │ └── ticket/ # 取票码页展示二维码和核销状态 │ ├── components/ │ │ ├── movie-card/ # 影片卡片纯展示 │ │ ├── seat-map/ # 座位矩阵组件只管画不管逻辑 │ │ └── date-tabs/ # 横向日期选择条 │ ├── utils/ │ │ ├── request.js # callFunction 的统一封装 错误码处理 │ │ ├── format.js # 价格分转元、日期格式化 │ │ └── seat.js # 座位矩阵生成与可选状态计算 │ └── images/ # 海报占位图、图标 └── cloudfunctions/ # 云函数后端 ├── getMovies/ # 查影片列表 ├── getSchedules/ # 按影片 日期查场次 ├── getSeatMap/ # 按场次查座位快照 ├── createOrder/ # 校验座位、锁座、写订单事务 ├── payCallback/ # 支付回调改订单状态 ├── cancelOrder/ # 取消订单释放座位 └── verifyTicket/ # 核销取票码看这个结构能读出几个设计取向。第一pages/seat和components/seat-map是分开的选座的计算逻辑集中在utils/seat.js里组件只负责接收矩阵和回调点击事件。这个拆法在选座页很好用——座位表动辄两三百个格子setData一次全量传会很卡拆开之后可以只更新变化的那一行。第二云函数是按「一个动作一个函数」切的不是按表切的。createOrder里同时操作座位和订单cancelOrder里同时改订单和座位边界跟着业务动作走而不是跟着数据表走。常见做法里也有人把所有逻辑塞进一个api云函数用event.action分发好处是冷启动只启一次坏处是函数体积大、权限不好收口。这个项目选了前者我一般也更倾向这种排查时一眼能定位是哪个函数出的问题。第三没有models/之类的抽象层。云函数里直接db.collection(orders).add(...)。对几百行的项目来说这不算问题但二次开发时要注意一旦你开始加多影院、加会员同一张表的写入会散落在四五个云函数里改字段容易漏那时候该抽就抽。启动前要改的地方只有两处app.js里的wx.cloud.init({ env: 你的环境ID })以及云函数目录下每个函数config.json里绑定的环境。这两个地方不一致最典型的后果是真机白屏后面第 5 章会专门讲。2.2 技术选型原生小程序 云开发为什么适合这类项目前端用的是原生小程序WXML / WXSS / JS没有上 uni-app 或 Taro。这不是保守是选座页逼出来的座位矩阵是个几十行乘几十列的网格每次点选都要重算一次可选状态还要做最多 4 张票的联动限制跨端框架多一层编译和 diff输入延迟就出来了。原生setData的路径更新比如this.setData({ matrix[3][5].status: 2 })在这种高频局部更新场景下最省事。后端用云函数 云数据库理由更实际。这个体量的项目单影院日均几十到几百单如果自建 Node 服务服务器、证书、域名、日志、备份这些运维事项的价值远超代码本身而小团队根本没有这个人。云开发把这一层抹掉了db.collection(orders).add()就是写库cloud.getWXContext().OPENID直接拿到用户身份不用自己搞登录态和 token 校验。代价也要说清楚事务能力有限。云开发的事务只能对单个文档做doc(id).get()/update()/remove()不支持在事务里where查询。这一点直接决定了createOrder的写法第 3 章会展开。云函数有并发和超时上限默认超时比较短座位多的时候循环更新很容易打满。聚合查询有结果条数限制做统计页时要注意分页或者分批。一句话总结选型单店体量、想快上线、没有运维走云开发日单过万或者要做多租户 SaaS趁早迁到自建服务。这也是我判断一份购票源码值不值得接手的第一个标准——它的数据访问是不是集中在云函数里如果是迁起来工作量可控如果散在页面里到处直连数据库那就很难受。2.3 数据模型影片、场次、座位、订单四张表怎么设计云数据库没有 schema全靠约定。这四个集合的字段约定建议先抄下来后面改代码全靠它对照。集合关键字段说明movies_id、title、poster、duration、rating、status、releaseDatestatus取ON/OFF下架不删数据schedules_id、movieId、hallName、showDate、startTime、price、cinemaIdshowDate存YYYY-MM-DD字符串startTime存HH:mmseats_id、scheduleId、row、col、type、status、lockTime、lockBystatus0 可售 / 1 已售 / 2 锁定 / 3 维修orders_id、openid、scheduleId、seatIds、totalPrice、status、outTradeNo、transactionId、createdAt、paidAtstatusPENDING/PAID/CANCELLED/USED两个设计点值得展开。一是seats是按场次快照存的不是按影厅模板实时算。也就是说排片的时候会往seats里插一批带scheduleId的文档一场一百个座位就一百条记录。看着冗余但好处很硬某场次椅子坏了可以直接把那条改成status: 3不影响别的场次影厅后来改了座位布局旧订单里的seatIds还能反查到「当时是 5 排 8 座」。如果用影厅模板实时算这两件事都要额外写兼容逻辑。二是价格用整数分存储。price: 4500表示 45 元前端用utils/format.js里的fen2yuan转成45.00再渲染。浮点数在订单金额上迟早出问题这种钱相关的字段统一用最小单位存是我接手任何交易类项目都要先确认的一件事。索引方面云数据库需要手动建。按查询频率至少给schedules建movieId showDate的复合索引给seats建scheduleId status给orders建openid createdAt降序和outTradeNo的唯一索引。最后这个尤其重要它是支付回调幂等的第一道防线第 3 章会讲。3. 核心购票链路选片、选场、选座、下单、支付怎么串起来3.1 场次渲染一次请求把整页数据拿回来影片详情页要做的事只有一件用户点开某部片子看到未来七天的场次点某一场进选座。这里的坑在于请求次数——如果先查日期、再按日期查场次、再按场次查影厅一个页面就是三次往返弱网下体验很差。源码的做法是一次性把整个影片的场次捞回来前端做分组。云函数大致长这样// cloudfunctions/getSchedules/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const _ db.command exports.main async (event) { const { movieId, days 7 } event if (!movieId) return { code: 4001, msg: 缺少 movieId } // 用字符串比较日期避免 Date 对象在不同环境下的时区偏移 const today new Date() const start formatDate(today) const end formatDate(new Date(today.getTime() days * 86400000)) const res await db.collection(schedules) .where({ movieId, showDate: _.gte(start).and(_.lte(end)), // 只取还没开场的场次已过场的直接不返回 status: ON }) .orderBy(showDate, asc) .orderBy(startTime, asc) .limit(200) .get() // 按日期分组前端拿到直接渲染日期条 const grouped {} res.data.forEach((item) { if (!grouped[item.showDate]) grouped[item.showDate] [] grouped[item.showDate].push(item) }) return { code: 0, data: grouped } } function formatDate(d) { const p (n) (n 10 ? 0 n : n) return ${d.getFullYear()}-${p(d.getMonth() 1)}-${p(d.getDate())} }几个参数的含义说一下。movieId是必传的没有就直接返回错误码别让它进数据库查询。days默认 7 天影院的排片一般也就排一周多的排了也没人看。返回结构是{ 日期: [场次数组] }前端用Object.keys(grouped)拿到日期列表渲染date-tabs选中日期再取对应数组。formatDate这里刻意没有用toISOString().slice(0, 10)。那玩意返回的是 UTC 日期在东八区晚上 8 点之后算出来的「今天」会比本地日期早一天于是当晚新建的场次第二天消失。这个坑我在两个项目里都见过属于典型的「本地测试永远正常、上线当晚就翻车」后面第 5 章还会单独列出来。limit(200)是个保险值。云数据库单次查询有条数上限超过会截断但不报错。一场影院一周的场次不会超过这个数但如果哪天有人加了多影厅批量排片这里就要改成游标分页否则用户会莫名其妙看不到后几天的场次。3.2 选座页的座位矩阵与状态机选座是整个项目最值得看的一页。后端返回的是一维座位数组每条带row和col前端要先还原成二维矩阵才能按行列渲染。// utils/seat.js /** * 把一维座位数组还原成 rows × cols 的矩阵 * param {Array} seats 后端返回的座位数组row/col 从 1 开始 * param {number} rows 总行数 * param {number} cols 总列数 * returns {ArrayArray} 二维数组无座位的格子为 null用于过道留白 */ function buildMatrix(seats, rows, cols) { const matrix [] for (let r 0; r rows; r) { matrix[r] new Array(cols).fill(null) } seats.forEach((seat) { // row/col 是 1 基转成 0 基下标 const r seat.row - 1 const c seat.col - 1 if (r 0 r rows c 0 c cols) { matrix[r][c] seat } }) return matrix } /** * 判断某个座位当前能否被点击 * param {Object|null} seat 座位对象null 表示这格是空的 * param {Array} selected 已选座位 id 列表 * param {number} maxCount 单笔最多选几张 */ function canSelect(seat, selected, maxCount 4) { if (!seat) return false // 空格子过道 if (seat.status ! 0) return false // 已售 / 已锁 / 维修 if (seat.type aisle) return false // 过道位不参与售卖 // 已经选中过的永远允许反选 if (selected.indexOf(seat._id) -1) return true return selected.length maxCount } module.exports { buildMatrix, canSelect }buildMatrix里那个new Array(cols).fill(null)是关键。有些写法直接用seats里的最大col当列数遇到最后一排只有一半座位影院常见的错位布局就会左边整体偏移选座图和实际影厅对不上。用固定rows和cols填null渲染时null的格子输出一个空白占位视觉上才对。页面里的点击逻辑保持得很薄// pages/seat/seat.js 片段 const { canSelect } require(../../utils/seat) Page({ data: { matrix: [], selected: [], maxCount: 4, totalPrice: 0 }, onSeatTap(e) { const { row, col } e.currentTarget.dataset const seat this.data.matrix[row][col] if (!canSelect(seat, this.data.selected, this.data.maxCount)) { if (seat seat.status ! 0) { wx.showToast({ title: 该座位已售出, icon: none }) } else if (this.data.selected.length this.data.maxCount) { wx.showToast({ title: 最多选${this.data.maxCount}张, icon: none }) } return } // 只更新变化的那一格避免整个矩阵重绘 const nextStatus this.data.selected.indexOf(seat._id) -1 ? 0 : 4 this.setData({ [matrix[${row}][${col}].status]: nextStatus, selected: this.toggleId(seat._id) }) this.calcPrice() } })这里用status: 4表示「本地已选中」和数据库里的 0/1/2/3 分开放避免本地选中状态和真实售出状态混在一起——这个区分很重要因为取消选中要还原成 0如果混用用户反选一次座位就变成「已售」只能刷新页面。setData用路径更新matrix[row][col].status而不是整个矩阵重传是这一页能不能跑顺的分水岭。一个 15 行 20 列的影厅有 300 个格子每次点击都全量传中低端机上的点击反馈会明显拖手。还有一处常见做法值得提maxCount不要硬编码在页面里。改成从schedules里读一个maxPerOrder字段运营想临时限制「每单最多 2 张」做活动改数据就行不用发版。选座页的最终产出是selected数组和一个总价点「确认选座」带着scheduleId seatIds跳到订单确认页。注意这时候还没有锁座座位在数据库里仍然是 0。真正的占用发生在下一步。3.3 下单事务与支付回调的幂等处理这是整个项目最容易出问题的地方也是最值得逐行看的地方。createOrder要保证三件事原子完成校验座位可用、把座位改成锁定、写订单。任何一步失败都要整体回滚否则会出现「座位锁了但没订单」或者「订单写了但座位没锁」这种对不上账的状态。// cloudfunctions/createOrder/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { const { OPENID } cloud.getWXContext() const { scheduleId, seatIds } event // 入口校验脏数据不要进事务 if (!scheduleId || !Array.isArray(seatIds) || seatIds.length 0) { return { code: 4001, msg: 参数不完整 } } const transaction await db.startTransaction() try { // 1. 逐条校验座位状态。云开发事务不支持 where 查询 // 只能按 doc 一个个来这是硬限制 let totalPrice 0 for (const id of seatIds) { const seatDoc await transaction.collection(seats).doc(id).get() const seat seatDoc.data if (!seat || seat.scheduleId ! scheduleId) { await transaction.rollback() return { code: 4002, msg: 座位不存在 } } if (seat.status ! 0) { await transaction.rollback() return { code: 4003, msg: 座位已被占用请重新选择 } } totalPrice seat.price || 0 } // 2. 锁座状态改成 2记录锁定人和锁定时间 for (const id of seatIds) { await transaction.collection(seats).doc(id).update({ data: { status: 2, lockBy: OPENID, lockTime: Date.now() } }) } // 3. 写订单状态 PENDING const orderRes await transaction.collection(orders).add({ data: { openid: OPENID, scheduleId, seatIds, totalPrice, status: PENDING, outTradeNo: ${Date.now()}${Math.floor(Math.random() * 10000)}, createdAt: Date.now() } }) await transaction.commit() return { code: 0, data: { orderId: orderRes._id, totalPrice } } } catch (err) { await transaction.rollback() return { code: 500, msg: err.message } } }参数说明scheduleId用来做二次校验防止有人拿 A 场次的座位 id 去下 B 场次的单seatIds是数组长度和maxCount对应totalPrice由服务端从座位价格累加算出来绝对不能用前端传过来的金额——这是收钱的地方前端传什么都不能信。outTradeNo的生成方式比较朴素时间戳加四位随机。单店体量够用但如果你打算做多影院建议换成影院ID 时间戳 自增序列否则同一毫秒两个用户下单有小概率撞号而outTradeNo一旦撞号支付回调查到的订单就是错的。事务里那个for循环是最慢的一段。20 个座位就是 20 次get加 20 次update加上事务本身的开销云函数默认超时很容易打穿。补救办法有两个一是把config.json里的超时时间调大二是把座位数限制在合理范围一单最多 4 到 6 张。常见做法是限制一单座位数业务上也说得通——谁买电影票一次买二十张。支付回调这一侧核心是幂等// cloudfunctions/payCallback/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { // 回调里带回来的商户订单号 const { outTradeNo, transactionId, returnCode } event // 支付失败的通知也要正常应答否则平台会一直重推 if (returnCode ! SUCCESS) return { errcode: 0, errmsg: ok } try { // 幂等的关键条件更新。只有 PENDING 的订单才允许改成 PAID const updateRes await db.collection(orders) .where({ outTradeNo, status: PENDING }) .update({ data: { status: PAID, transactionId, paidAt: Date.now() } }) // updated 为 0 说明这单已经被处理过了或者根本不存在 // 不管哪种情况都返回成功让回调停止重推 if (updateRes.stats.updated 0) { return { errcode: 0, errmsg: ok } } // 座位状态从「锁定」转「已售」 const orderRes await db.collection(orders).where({ outTradeNo }).get() const order orderRes.data[0] for (const id of order.seatIds) { await db.collection(seats).doc(id).update({ data: { status: 1 } }) } return { errcode: 0, errmsg: ok } } catch (err) { // 抛错让平台重推但重推可能造成重复处理 // 所以前面的条件更新必须扛得住 return { errcode: -1, errmsg: err.message } } }逻辑上的重点在于where({ outTradeNo, status: PENDING })。它把「查」和「判断状态」合并成了原子的一步并发进来两次回调只有一次能把updated变成 1另一次拿到 0 直接返回成功。这比「先 get 判断 status 再 update」安全得多后者在两次回调间隔极短时两边都能通过判断。后面的座位转「已售」放在订单更新之后即使这一步中途失败订单已经是PAID了用户能看到票座位状态可以靠定时任务补偿。反过来先改座位再改订单一旦订单更新失败座位就永远卡在「已售」但没人买只能人工修数据。钱的优先级永远高于库存这个顺序不能反。4. 后台与运营侧影片上架、场次排期、订单核销怎么做4.1 影片与场次管理写入约定和校验购票小程序的另一半是运营能力影院自己得能上片、排片。源码里这块没做成独立的 Web 后台而是塞在小程序里的一个隐藏运营页通过openid白名单判定身份——好处是不用再搭一套登录体系坏处是运营人员得在手机上排片体验一般。二次开发时如果影院的排片频率高建议单独做 H5 后台复用同一批云函数就行。排片写入的约定比代码更重要上片时movies只写元信息status默认OFF检查海报和时长无误后再改ON。直接ON的话首页会立刻出现一张没有海报的破图。排片时按movieId hallName showDate startTime做唯一性校验同厅同时间不能排两场。这个校验必须在云函数里做前端算不出来。排片成功后同步生成座位快照。生成逻辑要幂等如果该场次的seats已存在就跳过不要重复插。重复插的后果是同一个座位出现两条记录一条可售一条已售用户点了没反应。座位快照的生成代码大概是这个形状// cloudfunctions/createSchedule/index.js 片段 const ROWS 10 const COLS 16 const AISLE_COLS [4, 13] // 第 4、13 列为过道 async function generateSeats(scheduleId, hallName, basePrice) { const tasks [] for (let r 1; r ROWS; r) { for (let c 1; c COLS; c) { const isAisle AISLE_COLS.indexOf(c) -1 tasks.push({ scheduleId, hallName, row: r, col: c, type: isAisle ? aisle : normal, // 过道位不售卖直接标记为维修态避免被误选 status: isAisle ? 3 : 0, price: basePrice }) } } // 云数据库单次 add 只支持一条批量要用循环或者导入 for (const seat of tasks) { await db.collection(seats).add({ data: seat }) } }160 个座位就是 160 次add这必然超时。实际做法一般是先把座位数据导成 JSON 文件放云存储再用云函数批量导入或者干脆把整个座位矩阵以数组形式存成一条文档牺牲了单座位更新的便利换排片速度。这两种取舍没有绝对对错看你的影院是排片多还是改座多。排片频率高就选数组存储单座维修操作多就选一条一记录。过道位标记成status: 3而不是留空是因为渲染时前端只判断status ! 0就置灰逻辑统一不用在选座页再写一遍type aisle的分支。少一个分支就少一处可能写错的地方。4.2 订单核销与取票码验票端十秒能落地用户付完钱进pages/ticket看到的是一个取票码。这里最简单的实现是把orderId直接编码进二维码验票端扫码后调verifyTicket云函数// cloudfunctions/verifyTicket/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { const { orderId, staffOpenid } event // 只有 PAID 才能核销USED 是重复扫PENDING 是没付钱 const res await db.collection(orders) .where({ _id: orderId, status: PAID }) .update({ data: { status: USED, usedAt: Date.now(), usedBy: staffOpenid } }) if (res.stats.updated 0) { const orderRes await db.collection(orders).doc(orderId).get() const status orderRes.data orderRes.data.status if (status USED) return { code: 4001, msg: 该票已核销 } if (status PENDING) return { code: 4002, msg: 订单未支付 } return { code: 4003, msg: 无效票券 } } return { code: 0, msg: 核销成功 } }和支付回调一个套路条件更新 stats.updated判断。验票口是最不能出并发问题的地方两个检票员同时扫同一张票必须只有一个放行。usedBy记下操作人事后有争议能追溯。取票码本身建议加个短期签名别直接暴露orderId。源码里是明文改造成本不高云函数返回码值时用orderId 时间戳算个哈希拼进去验票时再校验一次时效超过 24 小时自动失效。这一步不做也不算致命但做过的人都知道明文 id 被截图转发给朋友蹭票是迟早的事。4.3 运营侧统计页的聚合查询运营页最后一块是「今天卖了多少」。这块用云数据库的聚合能力做// cloudfunctions/stats/index.js 片段 const db cloud.database() const $ db.command.aggregate exports.main async (event) { const { date } event // YYYY-MM-DD const start new Date(${date}T00:00:0008:00).getTime() const end start 86400000 const res await db.collection(orders) .aggregate() .match({ status: _.in([PAID, USED]), paidAt: _.gte(start).lt(end) }) .group({ _id: null, orderCount: $.sum(1), ticketCount: $.sum($.size($seatIds)), revenue: $.sum($totalPrice) }) .end() return { code: 0, data: res.list[0] || { orderCount: 0, ticketCount: 0, revenue: 0 } } }$.size($seatIds)是统计票数的关键比orderCount更贴近实际——一单买三张票对影院来说卖的是三张。revenue求和出来是分返回值别忘了在前端除 100。聚合查询有结果集上限日订单上千之后match完再group可能被截断。缓解办法是按小时分段查询再累加或者单独维护一张每日汇总表订单支付成功时顺手inc一次。我一般会选后者统计页要求的是快不是绝对实时。5. 避坑与排查座位锁不住、回调重复、真机白屏这几处最容易翻车5.1 两个人同时选到同一个座位现象压测时用两个账号同时点同一场的同一个座位两边都跳到了订单确认页最后两边都能进支付。付款后其中一个订单显示「已支付」但没有取票码另一个订单的座位状态是「已售」。原因前端选座只是本地状态真正的占用在后端。如果createOrder里是「先where查一遍 status 为 0 的座位再循环 update」两个请求可能都查到了「可用」然后都执行了 update。或者更隐蔽的一种事务里用了where查询——云开发事务根本不支持这个代码跑了但没生效等于没校验。解决事务内改成doc(id).get()逐条校验或者在非事务方案里用条件更新where({ _id: id, status: 0 }).update(...)然后检查stats.updated 1抢不到就整体回滚并返回明确的错误码前端收到 4003 就提示「座位已被占用」并刷新座位图。压测脚本我一般会写一个 20 并发的版本跑通才敢上线。5.2 支付成功但订单一直挂着「待支付」现象用户付款成功微信里也收到了扣款通知但小程序订单列表还是「待支付」点进去提示「请尽快完成支付」。客服只能手动退款。原因三种可能。一是回调函数抛异常了平台重推几次后放弃二是回调返回结构不对平台认为没收到应答一直重推三是回调里「先 get 判断 PENDING 再 update」重推时第一次已经改过状态第二次判断不通过直接 return 了但如果第一次改完订单、改座位那步挂了状态就是半拉子。解决回调改成条件更新updated 0一律返回成功返回结构严格按平台要求写别自己加字段再加一个每 5 分钟跑的定时任务做补偿扫描status: PENDING且createdAt超过 10 分钟、但支付侧能查到transactionId的订单直接改成PAID。补偿任务比事后手工退款省事得多。5.3 开发者工具正常真机扫码白屏现象模拟器里点哪哪正常真机预览进去一片白也没报错或者只有一行「云开发未初始化」。原因九成是环境 ID 对不上。app.js里wx.cloud.init({ env })写死了开发环境而真机走的是体验版云开发环境没绑到同一个 AppID 下或者云函数目录里每个函数的config.json各自写了一个环境有一个写错就整个链路断。剩下的一成是图片域名没配、或者用了只有开发者工具才有的 API。解决环境 ID 收到一个config.js里统一管理用wx.getAccountInfoSync().miniProgram.envVersion区分 develop / trial / release 三个环境真机上用小程序自带的调试面板看wx.cloud.callFunction的实际报错上线前把云开发环境和 AppID 的绑定关系在后台确认一遍这一步没确认其它排查都是白费。5.4 场次日期整体错一天现象晚上八点之后新排的场次第二天在列表里找不到或者明明排的是 15 号用户看到的却是 14 号。原因new Date()存进数据库变成 UTC 时间取出来格式化时又按本地时区算了一遍两头不一致。八点这个时间点是因为东八区偏移 8 小时晚上八点之后 UTC 已经是第二天了。解决日期统一存YYYY-MM-DD字符串时间统一存HH:mm字符串只在需要排序和判断是否过期时才转成时间戳而且转换函数只写一份放在utils/format.js。这条规矩定下来之后时区问题基本绝迹。5.5 点「去支付」转圈十几秒然后失败现象选完座点确认按钮转圈十几秒后弹「网络异常请重试」重试还是失败。原因createOrder里循环查座位加循环更新座位一多就超过云函数默认超时。云开发默认超时时间不长事务本身还有额外开销两个叠加直接打穿。解决一是把单笔订单座位数限制在 6 张以内业务上完全说得通二是在云函数的config.json里把timeout调高三是把校验和更新合并非关键动作写日志、发订阅消息拆到另一个云函数异步做。三条一起上正常单笔下单能压到 1 秒内。6. 二次开发从单影院改造到多影院 会员体系的落地思路接这类源码的人十个里有八个最后都要做两件事扩成多影院、加会员。这两件事的改造路径其实不一样别一起动。多影院改造是数据结构改造所有业务表加cinemaId字段schedules、seats、orders、movies如果各店片源不同全加所有云函数入参补cinemaId索引全部重建把cinemaId放到复合索引第一位前端加一个影院选择组件选中的影院存进app.globalDatarequest.js里统一带上。改动点多但机械一天能做完。唯一要想清楚的是首页逻辑是进来先选影院还是按定位推荐最近一家前者实现简单后者要接位置授权还涉及用户拒绝授权后的降级建议一期先做前者。会员体系是业务逻辑改造风险高得多。加一个users集合存openid、手机号、积分、等级订单确认页在算价时插入一层会员折扣支付成功后异步加积分退票时扣回。这里最容易出错的是「折扣和积分叠加算错」因为金额一旦算错就是真金白银。我的做法是永远在云函数里算最终价前端只负责展示和传usePoints: true/false这种开关绝不让前端传折扣后金额。改造顺序和验证方法我一般这么排阶段改动内容验证方式第一步加cinemaId不动业务逻辑用两家影院的测试数据跑完整购票流程确认数据不串第二步前端加影院切换切店后场次、座位、订单列表全部跟着变购物车清空第三步加users集合和积分字段老用户首次进入自动建档不阻塞购票第四步订单算价接入会员折扣用手工算的期望金额逐单比对含 0.01 元边界值第五步压测并发下单20 并发抢同一座位只能成功一单第三步有个细节值得单独说老用户第一次进新版本时并没有users记录如果建档逻辑放在下单流程里一旦建档失败整个下单就挂了。我一般放在app.js的onLaunch里异步做失败了也不影响主流程下次进来再补。这种「非核心链路不阻塞核心链路」的判断是改别人源码时最该先建立的习惯。最后一个技巧关于怎么快速确认一份购票源码靠不靠谱别看页面先搜三个东西——搜setData看看有没有全量更新大数组的搜startTransaction看看事务里有没有where搜outTradeNo看看回调是不是条件更新。这三处只要有一处写错这个项目就一定在某个时段出过对不上账的事故。我从被一次并发锁座事故坑掉一个周末之后每次拿到交易类源码都先跑一遍这三项检查再决定是接着改还是重写。希望帮到你。本文还有配套的精品资源点击获取