

> 本文是「小i约球诞生记」系列文章之一。  
> 小i约球是一个微信小程序，主要帮乒乓球、羽毛球、台球、网球爱好者找到附近合适的球友。本文从一个具体技术或产品问题切入，记录约球小程序从 0 到 1 过程中的设计取舍。
>

## 前言

做小i约球之前，我对这个项目的判断很简单：它应该是一个轻量的小程序。

用户发布约球名片，其他人查看附近球友，再打招呼联系。早期不需要复杂后台，不需要独立 App，也不需要一套很重的微服务架构。

所以第一版技术选型，我选择了微信小程序 + 微信云开发。

现在回头看，这个选择有明显的好处，也有一些后面才慢慢感受到的限制。

这篇主要聊技术选型，不展开具体代码。
## 一开始为什么选云开发

最直接的原因是：快。

小i约球这种产品，早期最重要的不是把架构设计得多漂亮，而是尽快验证几个关键问题：

- 用户是否愿意发布约球名片
- 附近球友列表是否有价值
- 公众号提醒是否能带来回访
- 本地群和小程序是否能形成配合

如果一开始就自建后端，需要处理服务器、数据库、部署、域名、HTTPS、鉴权、日志、运维等一堆事情。它们都重要，但不是第一阶段最需要验证的东西。

云开发的优势在这里就很明显：

- 小程序端可以直接调用云函数
- 云函数天然拿到微信上下文
- 云数据库和小程序生态集成度高
- openapi 调用比较方便
- 定时任务配置成本低
- 文件上传、图片存储、用户身份都能快速串起来

对于一个早期个人项目来说，这些东西能省掉大量时间。

## 当时的整体架构

项目整体结构比较典型：

- `miniprogram/`：小程序页面、组件、工具方法
- `cloudfunctions/`：后端云函数
- 云数据库：存用户、约球名片、消息、问答、快速约球、本地群等数据

小程序端通过 `wx.cloud.callFunction` 调用云函数。云函数内部再根据 `action` 分发到不同逻辑。

大致形态是：

```text
小程序页面
    ↓ wx.cloud.callFunction
云函数
    ↓
云数据库 / 微信 openapi
```

这套模式很适合早期快速开发。

比如用户模块、约球名片模块、附近匹配模块、消息模块、问答模块、快速约球模块，都可以拆成独立云函数。每个云函数只关心自己的业务，部署时也可以单独上传。

## 真实做下来遇到的限制

如果只看前面的部分，云开发听起来很省心。

但项目做深以后，也会慢慢遇到一些边界。


## 1. 超时时间限制会影响批处理

云函数有执行时间限制。

对于普通请求问题不大，但对批量任务, 或者AI大模型调用就比较敏感。

比如：

- 遍历临时匹配队列
- 批量发送公众号消息
- 批量处理问答通知
- 批量生成或同步数据

这些逻辑如果一次处理太多，就可能接近超时。

所以后面必须做批次控制和并发控制。比如问答通知不能一次性无限发，而是写入临时集合，再由定时任务分批消费。

## 4. 没有 Redis

云开发默认没有 Redis。
这会影响很多常见后端设计。

比如：

- 短期缓存
- 分布式锁
- 限流
- 去重
- 队列状态
- 临时会话

在自建后端里，这些很自然会想到 Redis。但在云开发里，很多时候只能用数据库字段、临时集合、时间戳来替代。

比如小i约球里，附近匹配和收藏提醒都用了临时集合：
它们本质上是在用数据库模拟队列。
这个方案能跑，但要自己处理重复、失败、删除、批量消费等问题。

## 5. 没有真正的消息队列

这点和没有 Redis 类似，但影响更大。

小i约球里很多场景天然适合 MQ：

- 发布名片后异步通知附近球友
- 收藏别人后异步通知对方
- 问答发布后异步推送给相关用户
- 快速约球后异步通知附近人和附近群

如果有 MQ，设计会很自然：

```text
业务事件
    ↓
消息队列
    ↓
消费者
    ↓
发送通知 / 写日志 / 重试
```

但云开发里没有这么完整的消息队列能力，所以我用了“数据库集合 + 定时任务”的方式模拟。

这个方式的好处是简单，坏处也明显：

- 实时性不如 MQ
- 失败重试要自己写
- 消费状态要自己维护
- 并发控制要自己处理
- 数据清理要特别注意

早期可以接受，但项目继续变大后，就会成为一个需要重点治理的模块。

## 6. 本地调试和工程化能力有限

这个项目主要依赖微信开发者工具调试。

小程序端、云函数、云数据库、openapi 权限，都和微信开发者工具绑定比较深。

这对快速开发是好事，但对工程化也有一些限制：

- 没有传统后端那种完整本地启动流程
- 云函数部署依赖开发者工具操作
- 多环境切换容易靠配置变量手动改
- 自动化测试和 CI 不如常规 Node 服务自然

项目早期问题不大。等功能复杂以后，就会开始希望有更清晰的本地调试、部署和测试流程。

## 为什么没有一开始自建后端

如果重新做，我仍然不会一开始就自建后端。

原因很简单：早期最大的不确定性不是技术，而是产品是否成立。

自建后端确实更自由：

- 可以用 Redis
- 可以用 MQ
- 可以自己设计数据库
- 可以做完整日志和监控
- 可以更好地做 CI/CD

但这些自由也意味着更多成本。

对小i约球这种早期产品来说，先验证“附近球友匹配”这个场景，比先搭一套完整后端更重要。

所以我的判断是：

早期用云开发是对的。  
但要知道它不是没有代价。

## 我的选型结论

如果你也在做类似的小程序项目，我会这样判断。

适合用云开发的情况：

- 你是个人或小团队
- 产品还在验证阶段
- 主要场景在微信生态内
- 后端逻辑不算特别重
- 需要快速接入微信 openapi
- 能接受一定的平台限制

不太适合完全依赖云开发的情况：

- 业务有大量实时队列
- 强依赖 Redis、MQ、复杂缓存
- 需要大量后台批处理
- 对可观测性和自动化部署要求很高
- 未来可能脱离微信生态

小i约球目前还处在比较适合云开发的阶段，但已经开始遇到一些边界。比如消息队列、批量通知、定时任务、access_token 管理、跨函数重复代码，这些都需要后续慢慢治理。

## 总结

小i约球一开始选择云开发，核心原因是快速验证。

它让我很快把用户、约球名片、附近匹配、公众号通知、内容安全、定时任务这些能力串起来。对于一个早期微信小程序来说，这个效率很重要。

但真正做起来以后，也会发现云开发不是万能后端。

它的限制也很清楚：云函数数量和大小、超时时间、没有 Redis、没有真正的消息队列、本地工程化能力有限。

所以我的态度不是“云开发好”或者“云开发不好”，而是：

在早期，它能帮你快速把产品跑起来；  
等业务变复杂以后，你要知道哪些地方是在借平台能力，哪些地方是在绕平台限制。

---

本文属于「小i约球诞生记」系列。


本文是「小i约球诞生记」系列文章之一。   小i约球是一个微信小程序，主要帮乒乓球、羽毛球、台球、网球爱好者找到附近合适的球友。本文从一个具体技术或产品问题切入，记录约球小程序从 0 到 1 过程中的设计取舍。

小i约球诞生记01：为什么一开始选择微信云开发

小i约球是一个微信小程序，主要帮乒乓球、羽毛球、台球、网球爱好者找到附近合适的球友，本文记录一开始的技术选型思考，为什么选用小程序云开发

开发工具

后端

架构设计

微服务架构

内容安全

代码解释

消息队列

云数据库

云函数

服务器

数据库

Redis

2026上云采购 | AI焕新·智启新局

coding

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

小i约球诞生记01：为什么一开始选择微信云开发-腾讯云开发者社区-腾讯云

小i约球诞生记01：为什么一开始选择微信云开发

小i约球诞生记01：为什么一开始选择微信云开发

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐