小程序云开发：一个人也能撑起完整后端

做小程序这几年，我越来越觉得：对个人开发者和小团队来说，真正的瓶颈往往在于后端，而非前端页面。一个稍微像样的功能，就要服务器、数据库、接口、鉴权、部署、监控，一套下来光运维就够喝一壶。微信小程序的云开发，恰好把这一整块收进去了。这篇文章聊聊我在实际项目里怎么用云开发，以及哪些地方值得注意。

云开发到底给了什么

简单说，云开发把后端能力封装成小程序可以直接调用的服务，核心是四块：

• 云数据库：文档型数据库，支持在小程序端和云函数里读写，自带权限控制。
• 云函数：跑在云端的 Node.js 函数，用来处理敏感逻辑和第三方接口调用。
• 云存储：文件上传下载，图片、音视频都能放，配合 CDN 使用。
• 云调用：在云函数里免鉴权调用微信开放接口，比如获取用户信息、发送订阅消息。

这四块组合起来，一个完整的业务闭环基本就够了。我做过一个预约类小程序，从零到上线只用了两周，没有买过一台服务器。

初始化与第一次调用

在 app.js 里初始化一次即可，后续页面直接用 wx.cloud：

App({
  onLaunch() {
    if (!wx.cloud) {
      console.error('请使用 2.2.3 或以上的基础库')
      return
    }
    wx.cloud.init({
      env: 'your-env-id',
      traceUser: true
    })
  }
})

之后在页面里查数据：

const db = wx.cloud.database()
db.collection('orders')
  .where({ status: 'paid' })
  .orderBy('createTime', 'desc')
  .limit(20)
  .get()
  .then(res => {
    this.setData({ list: res.data })
  })

注意小程序端单次查询默认最多 20 条，云函数里是 100 条，分页要自己算好 skip。

什么时候必须用云函数

云数据库的权限分四种：仅创建者可读写、所有用户可读仅创建者可写、所有用户可读、仅管理端可读写。前三种能直接在小程序端操作，最后一种只能走云函数。我的经验是：

• 用户自己的数据（收藏、草稿、个人资料）用「仅创建者可读写」，前端直连，省事。
• 公开内容（文章、商品列表）用「所有用户可读」，同样前端直连。
• 涉及金额、库存、积分、审核状态的，一律「仅管理端可读写」，全部走云函数。

云函数里拿数据库引用和外面略有不同：

const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()

exports.main = async (event) => {
  const wxContext = cloud.getWXContext()
  const openid = wxContext.OPENID

  // 扣减库存，用原子操作避免并发问题
  const res = await db.collection('goods')
    .where({ _id: event.goodsId, stock: db.command.gt(0) })
    .update({ data: { stock: db.command.inc(-1) } })

  if (res.stats.updated === 0) {
    return { code: 1, msg: '库存不足' }
  }
  return { code: 0, openid }
}

db.command.inc 这类原子操作很关键，别先查再写，并发下必出问题。

几个实际会碰到的点

冷启动与超时

云函数默认超时 3 秒，冷启动时偶发超时。我的做法是把超时调到 10 秒，同时把耗时逻辑拆小，别在一个函数里串行调三四个外部接口。对实时性要求不高的任务，可以用定时触发器异步处理。

数据库索引

数据量上来后，没索引的查询会明显变慢。在控制台的数据库面板里给常用查询字段建索引，尤其是 where 和 orderBy 组合的字段。这一步很多人上线后才想起来。

环境隔离

建议至少建两个环境：开发环境和生产环境。云函数、数据库、存储都是按环境隔离的，切换时只改 env 参数。上线前在开发环境跑一遍完整流程，能省掉很多线上事故。

费用

云开发有免费额度，个人项目基本够用。超出后按量计费，主要成本在云函数调用次数、数据库读写次数和存储流量。控制成本的办法很朴素：列表分页、图片压缩后再上传、避免在 onShow 里无脑重复请求。

适合谁，不适合谁

云开发适合：个人开发者、MVP 验证、内容型与工具型小程序、需要快速上线的小项目。它把运维成本压到接近零，让一个人能独立完成前后端。

不太适合：需要复杂事务和强一致性的金融类业务、已有成熟后端体系需要对接的项目、对数据库结构有严格关系型要求的场景。这些情况下，云开发可能只是过渡方案。

我的建议是：先用云开发把产品跑起来，验证需求。等业务真的增长到云开发扛不住的时候，再考虑迁移，那时候你至少已经知道用户要什么了。