小i约球诞生记01：为什么一开始选择微信云开发
本文是「小i约球诞生记」系列文章之一。
小i约球是一个微信小程序，主要帮乒乓球、羽毛球、台球、网球爱好者找到附近合适的球友。本文从一个具体技术或产品问题切入，记录约球小程序从 0 到 1 过程中的设计取舍。
小程序：微信搜索「小i约球」
前言
做小i约球之前，我对这个项目的判断很简单：它应该是一个轻量的小程序。
用户发布约球名片，其他人查看附近球友，再打招呼联系。早期不需要复杂后台，不需要独立 App，也不需要一套很重的微服务架构。
所以第一版技术选型，我选择了微信小程序 + 微信云开发。
现在回头看，这个选择有明显的好处，也有一些后面才慢慢感受到的限制。
这篇主要聊技术选型，不展开具体代码。
一开始为什么选云开发
最直接的原因是：快。
小i约球这种产品，早期最重要的不是把架构设计得多漂亮，而是尽快验证几个关键问题：
- 用户是否愿意发布约球名片
- 附近球友列表是否有价值
- 公众号提醒是否能带来回访
- 本地群和小程序是否能形成配合
如果一开始就自建后端，需要处理服务器、数据库、部署、域名、HTTPS、鉴权、日志、运维等一堆事情。它们都重要，但不是第一阶段最需要验证的东西。
云开发的优势在这里就很明显：
- 小程序端可以直接调用云函数
- 云函数天然拿到微信上下文
- 云数据库和小程序生态集成度高
- openapi 调用比较方便
- 定时任务配置成本低
- 文件上传、图片存储、用户身份都能快速串起来
对于一个早期个人项目来说，这些东西能省掉大量时间。
当时的整体架构
项目整体结构比较典型：
- `miniprogram/`：小程序页面、组件、工具方法
- `cloudfunctions/`：后端云函数
- 云数据库：存用户、约球名片、消息、问答、快速约球、本地群等数据
小程序端通过 `wx.cloud.callFunction` 调用云函数。云函数内部再根据 `action` 分发到不同逻辑。
大致形态是：
小程序页面，↓ wx.cloud.callFunction，云函数，云数据库 / 微信 openapi。
这套模式很适合早期快速开发。
比如用户模块、约球名片模块、附近匹配模块、消息模块、问答模块、快速约球模块，都可以拆成独立云函数。每个云函数只关心自己的业务，部署时也可以单独上传。
真实做下来遇到的限制
如果只看前面的部分，云开发听起来很省心。
但项目做深以后，也会慢慢遇到一些边界。
1. 超时时间限制会影响批处理
云函数有执行时间限制。
对于普通请求问题不大，但对批量任务, 或者AI大模型调用就比较敏感。
比如：
- 遍历临时匹配队列
- 批量发送公众号消息
- 批量处理问答通知
- 批量生成或同步数据
这些逻辑如果一次处理太多，就可能接近超时。
所以后面必须做批次控制和并发控制。比如问答通知不能一次性无限发，而是写入临时集合，再由定时任务分批消费。
4. 没有 Redis
云开发默认没有 Redis。 这会影响很多常见后端设计。
比如：
- 短期缓存
- 分布式锁
- 限流
- 去重
- 队列状态
- 临时会话
在自建后端里，这些很自然会想到 Redis。但在云开发里，很多时候只能用数据库字段、临时集合、时间戳来替代。
比如小i约球里，附近匹配和收藏提醒都用了临时集合： 它们本质上是在用数据库模拟队列。 这个方案能跑，但要自己处理重复、失败、删除、批量消费等问题。
5. 没有真正的消息队列
这点和没有 Redis 类似，但影响更大。
小i约球里很多场景天然适合 MQ：
- 发布名片后异步通知附近球友
- 收藏别人后异步通知对方
- 问答发布后异步推送给相关用户
- 快速约球后异步通知附近人和附近群
如果有 MQ，设计会很自然：
业务事件，消息队列，消费者，发送通知 / 写日志 / 重试。
但云开发里没有这么完整的消息队列能力，所以我用了“数据库集合 + 定时任务”的方式模拟。
这个方式的好处是简单，坏处也明显：
- 实时性不如 MQ
- 失败重试要自己写
- 消费状态要自己维护
- 并发控制要自己处理
- 数据清理要特别注意
早期可以接受，但项目继续变大后，就会成为一个需要重点治理的模块。
6. 本地调试和工程化能力有限
这个项目主要依赖微信开发者工具调试。
小程序端、云函数、云数据库、openapi 权限，都和微信开发者工具绑定比较深。
这对快速开发是好事，但对工程化也有一些限制：
- 没有传统后端那种完整本地启动流程
- 云函数部署依赖开发者工具操作
- 多环境切换容易靠配置变量手动改
- 自动化测试和 CI 不如常规 Node 服务自然
项目早期问题不大。等功能复杂以后，就会开始希望有更清晰的本地调试、部署和测试流程。
为什么没有一开始自建后端
如果重新做，我仍然不会一开始就自建后端。
原因很简单：早期最大的不确定性不是技术，而是产品是否成立。
自建后端确实更自由：
- 可以用 Redis
- 可以用 MQ
- 可以自己设计数据库
- 可以做完整日志和监控
- 可以更好地做 CI/CD
但这些自由也意味着更多成本。
对小i约球这种早期产品来说，先验证“附近球友匹配”这个场景，比先搭一套完整后端更重要。
所以我的判断是：
早期用云开发是对的。 但要知道它不是没有代价。
我的选型结论
如果你也在做类似的小程序项目，我会这样判断。
适合用云开发的情况：
- 你是个人或小团队
- 产品还在验证阶段
- 主要场景在微信生态内
- 后端逻辑不算特别重
- 需要快速接入微信 openapi
- 能接受一定的平台限制
不太适合完全依赖云开发的情况：
- 业务有大量实时队列
- 强依赖 Redis、MQ、复杂缓存
- 需要大量后台批处理
- 对可观测性和自动化部署要求很高
- 未来可能脱离微信生态
小i约球目前还处在比较适合云开发的阶段，但已经开始遇到一些边界。比如消息队列、批量通知、定时任务、access_token 管理、跨函数重复代码，这些都需要后续慢慢治理。
总结
小i约球一开始选择云开发，核心原因是快速验证。
它让我很快把用户、约球名片、附近匹配、公众号通知、内容安全、定时任务这些能力串起来。对于一个早期微信小程序来说，这个效率很重要。
但真正做起来以后，也会发现云开发不是万能后端。
它的限制也很清楚：云函数数量和大小、超时时间、没有 Redis、没有真正的消息队列、本地工程化能力有限。
所以我的态度不是“云开发好”或者“云开发不好”，而是：
在早期，它能帮你快速把产品跑起来； 等业务变复杂以后，你要知道哪些地方是在借平台能力，哪些地方是在绕平台限制。
---
本文属于「小i约球诞生记」系列。
项目官网：https://iyueqiu.cn 微信小程序：搜索「小i约球」
