云开发三年，我踩过的坑和真香时刻

上周有个朋友问我，接了个小程序的私活，后端用云开发行不行。我想了想，回他一句：看你接的是什么活。如果是那种老板预算五千、三天要上线、还要带个后台管理的东西，云开发基本是唯一解。但如果需求里出现了“实时对账”“复杂报表导出”这种词，我劝你早点跑。

我从2021年开始在项目里用云开发，前后做了十几个小程序，有纯云开发的，也有云开发加自建服务器的混合方案。这篇不讲官方文档里那些“三步创建环境”的流程，只聊我实际踩过的坑和后来觉得真香的地方。

先说结论：它适合什么，不适合什么

云开发本质是把数据库、云函数、存储、CDN 打包成一个开箱即用的后端。对独立开发者来说，省掉的最大成本不是钱，是运维心智。不用买服务器、不用配域名备案、不用管 SSL 证书过期，这些琐事在小项目里占的时间比写业务代码还多。

但它不适合的场景也很明确：

• 需要复杂 SQL 查询、多表 JOIN 的业务。云开发的数据库是文档型，聚合能力有，但写起来比 SQL 别扭得多。
• 需要长时间运行的任务，比如视频转码、大批量数据导出。云函数有超时限制，默认几秒到几十秒，硬扛会很难受。
• 对数据迁移有强需求的。一旦数据量上去想迁走，导出和重建的成本不低，这点要有心理准备。

数据库查询的那些反直觉的地方

刚用的时候最容易翻车的是查询权限。小程序端直接查数据库，默认权限是“仅创建者可读写”，很多人不知道，结果发现列表页一条数据都没有，还以为是代码写错了。

另一个坑是分页。云开发的 skip 在数据量大时性能会明显下降，因为它本质上是跳过再取。我的做法是尽量用游标分页，拿上一页最后一条的某个有序字段做条件：

const db = wx.cloud.database()
const pageSize = 20
let lastTime = null

async function loadMore() {
  let query = db.collection('orders').orderBy('createTime', 'desc')
  if (lastTime) {
    query = query.where({ createTime: db.command.lt(lastTime) })
  }
  const res = await query.limit(pageSize).get()
  if (res.data.length) {
    lastTime = res.data[res.data.length - 1].createTime
  }
  return res.data
}

这样每次查询都走索引，翻到第几十页也不会明显变慢。代价是不能直接跳到第 N 页，但小程序场景里下拉加载本来就比页码翻页更自然。

云函数的冷启动，别等上线才发现

云函数冷启动这件事，文档里提过，但很多人没当回事。我第一次遇到是用户反馈“点按钮要等两三秒才反应”，本地测试完全复现不了，因为本地调用频繁，函数一直是热的。

后来我的处理方式是：把用户高频触发的逻辑尽量放在小程序端直接操作数据库，云函数只处理需要权限校验或者涉及敏感数据的部分。另外，给关键云函数配置定时触发器，每隔几分钟 ping 一下，保持温热，虽然有点土，但确实有效。

还有一个细节，云函数里初始化 SDK 的代码要放在函数体外面，不要每次调用都重新初始化。这个习惯能省下不少时间。

真香的地方：文件存储和内容安全

说点好的。云开发的存储配合小程序端的 wx.cloud.uploadFile，上传图片的体验是真的顺，不用自己签名、不用管 CDN 回源。用户传头像、传凭证照片这种需求，几行代码就搞定。

还有内容安全接口。做社区类小程序时，文本和图片的违规检测是刚需，云开发直接提供了调用入口，省掉了自己去对接第三方审核服务的麻烦。虽然检测不是百分之百准，但作为第一道过滤足够了。

我的经验是：能用平台自带的能力就别自己造轮子，尤其是审核、存储这类边缘但必须有的功能，自己维护的成本远高于想象。

成本这块，说点实在的

很多人担心云开发贵。我的实际感受是，小项目阶段基本在免费额度内，日活几千的量级，每月几十块到一两百块就能覆盖。真正烧钱的是存储流量和云函数调用次数，如果小程序里有大量图片展示，CDN 流量费要盯紧。

建议上线前把资源用量监控打开，设置告警。我有个项目因为一个循环里反复调云函数，一晚上跑掉了几十块，虽然不多，但那种“钱在悄悄流走”的感觉很不舒服。

最后一句

云开发不是银弹，但对独立开发者和小团队来说，它把“从想法到上线”的路径缩短了很多。我的建议是：新项目先用云开发跑通 MVP，验证需求；等业务真的长起来、遇到瓶颈了，再考虑迁移或者混合架构。过早优化后端，很多时候是在为一个还不存在的用户量买单。