去年接了一个项目：客户是做上门清洁服务的，想做一个微信小程序让客户在线预约，后台用 WordPress 管理订单。
这篇文章不讲具体代码，讲技术选型的思路、架构设计和踩过坑——对想做类似系统的朋友应该有用。
项目背景
客户需求：
– 用户在微信小程序里选择服务（日常保洁、深度清洁、开荒清洁等）
– 选择上门时间（精确到 2 小时时段）
– 在线支付（微信支付）
– 管理员在后台查看订单、排单、改状态
开发限制：
– 客户预算有限（1 万出头）
– 需要有后台管理界面，不能光靠小程序后台
– 后期可能需要加新功能
技术架构选型
为什么选 uni-app + WordPress REST API
| 方案 | 优点 | 缺点 |
|---|---|---|
| uni-app + WP REST API | 开发快，后台免费，生态成熟 | 性能上限有限 |
| 原生微信小程序 + 自建后端 | 性能最优 | 开发成本高，维护复杂 |
| uni-app + 云开发 | 后端不需要服务器 | 小程序云开发 API 跟传统后端差距大 |
选 uni-app + WordPress REST API 的核心原因就一个：快。客户预算有限，要求一个月内上线。这种项目不能从零搭后端，WordPress 本身的用户系统、文章系统、自定义字段功能已经很成熟，直接拿来当后台用。
架构图（简化）
[微信小程序] ←→ [WordPress REST API] ←→ [WordPress 后台管理]
↓ ↓
微信支付 MySQL 数据库
（订单/用户/服务）
核心功能实现思路
1. 服务展示
在 WordPress 后台用自定义文章类型（Custom Post Type）创建”服务”模块。每个服务包含：
– 服务名称
– 服务描述
– 价格（不同面积/时长不同价格怎么办？用 ACF 高级自定义字段创建价格表）
– 服务时长（决定了时间段怎么切）
小程序端通过 REST API 获取服务列表：GET /wp-json/wp/v2/services
2. 时间预约
这是最复杂的部分，核心逻辑分三步：
第一步：后台设置可用时段
在 WordPress 后台设置每天的可预约时间段。比如上午 8:00-12:00，下午 14:00-18:00，每个时间槽 2 小时。
第二步：小程序端显示可选时间
用户选完服务后，调接口获取未来 7 天每个时段是否可约。后端逻辑是：这个时间槽的已约单数是否已达上限（比如每时段最多接 2 单）。
第三步：锁定机制
用户选定时间后，支付前锁定该时段（5-10 分钟）。超时未支付自动释放。避免两个人同时约同一个时段。
3. 支付流程
用户确认预约 → 后端生成订单 → 返回订单ID
→ 小程序调用微信支付 API → 支付成功
→ 微信服务器回调你的后端 → 更新订单状态 → 发模板消息通知
支付回调是坑最多的地方。微信支付的异步通知必须正确验证签名，而且微信要求 5 秒内返回确认，否则会重试——可能导致重复回调。
4. 后台管理
WordPress 后台做了一个简单的订单管理页面：
– 订单列表（按日期、状态筛选）
– 点击订单查看详情
– 改状态：待确认 → 已确认 → 服务中 → 已完成 → 已取消
– 手动分配服务人员（用 ACF 关联字段）
状态变更时自动触发邮件通知（WP Mail SMTP）和小程序模板消息。
踩坑记录
坑 1：WordPress REST API 的鉴权
小程序是公开访问的，但预约接口需要用户登录。WordPress REST API 的认证方式选了 JWT（JSON Web Token）。
麻烦的地方： 微信小程序的登录流程是「wx.login → 获取 code → 后端用 code 换 openid → 创建/匹配 WP 用户 → 返回 JWT token」。这套流程在跟 WP 默认的登录系统对接时，需要额外写一个插件处理微信登录逻辑。
坑 2：时间槽并发问题
两个人同时约同一个时段，后端怎么保证不超约？
方案：MySQL 的行锁（SELECT … FOR UPDATE）。在检查该时段剩余名额和写入订单之间加事务，确保原子性。不优雅，但够用。
坑 3：微信支付金额精度
微信支付金额单位是分。小程序前端显示的是元（88.00），传参时必须 * 100 转成分为单位。这个细节搞反了一次，客户收到 8800 元的订单提醒，还好及时发现。
坑 4：WordPress 的小程序 REST API 响应慢
WordPress 在没有缓存的情况下，每个 REST API 请求都会加载完整的 WordPress 环境。预约接口多了会慢。
解决： 加 Redis 对象缓存 + 对服务列表这种不经常变的接口做 API 缓存。
成本汇总
| 项目 | 费用 |
|---|---|
| 微信小程序认证 | ¥300/年 |
| WordPress 主机（轻量云） | ¥68/月 |
| 域名 | ¥60/年 |
| SSL 证书 | 免费（Let’s Encrypt） |
| 插件（ACF Pro 等） | ¥0（用免费替代） |
| 开发费用 | ¥12,000 |
| 首年总成本 | 约 ¥14,000 |
如果重新做会怎么选？
现在来看，如果预算允许（2-3 万），我会换一个方案：
- 后端用 Laravel 或直接用成熟的 SaaS（如 Calendly API），避免 WordPress 在高并发预约场景下的性能问题
- 小程序用 uni-app 继续保留，一套代码能转 H5 备用
但如果预算还是 1 万出头，WordPress REST API 仍然是最务实的选择——它解决问题够快，客户能接受。
需要帮忙？私信我。
想做类似的预约系统？把你的业务场景告诉我，帮你评估技术方案和大概预算。