1.2 为什么是云开发而不是 SAAS

选型会上，第三个选项被拍在桌上：既然目标是快点上线，为什么不直接用一个建站 SaaS？拖拽几下就能出一个图文站，一个月几十块钱，连代码都不用写。这个提议一度很有说服力，我们认真调研了整整三天，最后还是放弃了。这一节讲讲三条路对比的结论，以及云开发到底给了我们什么 SaaS 给不了的东西。

场景：三条路摆在面前

需求还是那个图文应用，但多了几条硬要求：

  • 正文要支持 Markdown 自定义排版，不是固定模板
  • 后台逻辑要能自己写，比如审核驳回后的二次修改流程
  • 数据要能导出，用户内容不能锁死在平台里
  • 将来要能加小程序端，不是只有一个 H5

这四条不是拍脑袋想的，每条背后都有具体场景：我们的早期用户里有一部分是技术写作者，排版自由度直接决定他们愿不愿意来；审核驳回二次修改牵扯到状态机，SaaS 的固定流程根本表达不了；而数据导出这条，是被朋友的真实迁移经历教育出来的，后面踩坑一节会细讲。

带着这四条去问市面上的建站 SaaS，基本全军覆没：模板好看但改不了排版，数据导出要么没有要么只给图片压缩包，自定义逻辑更是想都别想。

调研期间我们还整理过一张对比清单，把当时认真考虑过的几个方案逐条打分，结果越看越清楚：便宜的那部分能力，恰恰是我们最在乎的那部分。

我们在意的点 某SaaS A 某SaaS B 云开发
Markdown 排版 仅富文本 部分支持 完全自定义
自定义后端 不支持 付费定制 云函数随便写
数据导出 仅正文文本 图片打包 开放API全量导
小程序扩展 收费模块 无 一套SDK直连
月成本 四十九元起 九十九元起 免费额度起步

打完这张表，争论就基本结束了。云开发每一项都是满分或接近满分，而两个 SaaS 各自都在关键项上差一口气。

三条路的对比表

对比项 建站 SaaS 开源 CMS 自建 云开发
上手速度 半天出站 一周左右 一到两天
页面自由度 模板内有限 完全自由 完全自由
自定义后端逻辑 不支持 自己写 云函数随便写
数据可导出 大多不支持 自己备份 开放 API 可导
运维负担 零 全靠自己 平台托管
月成本 几十元起 服务器加域名 免费额度起步
扩展小程序端 看平台 自己重写 SDK 直连

结论很清楚：SaaS 赢在速度，CMS 赢在自由但输在运维，云开发两边都占了中间。对我们这个还要长期迭代的项目，只有云开发同时满足自由和省事。

方案：云开发给了什么

真正打动我的，是它把一个后端该有的零件都做成了即插即用。选型时我们整理的能力清单：

能力 干什么用 对应本项目的模块
文档数据库 存文章、评论 文章集合与用户集合
对象存储 存图片和封面 图文配图直传
云函数 后端业务逻辑 列表分页、审核回调
静态托管 前端页面发布 H5 站点部署
登录鉴权 微信与匿名登录 用户体系
内容审核 图文合规检查 发布前拦截

每个能力单独拿出来都有官方文档对应，云开发文档入口在 cloud.tencent.com/document/product/614，选型阶段我翻得最多的就是它。它和对象存储 COS、云函数 SCF 这些单品的关系可以这么理解：云开发是把它们打包成一整套后端方案，配上权限、登录和托管，你只面对一个控制台、一套 SDK，而不是对着一堆散件各自配置。

对从其他云产品迁移过来的同学，这个打包关系需要适应一下：比如上传图片不用再自己去 COS 控制台新建桶、配跨域，环境创建时就帮你备好了。想深入了解各单品能力的，可以对应翻 COS 文档 cloud.tencent.com/document/product/436 和 SCF 文档 cloud.tencent.com/document/product/598。

代码片段：先验证最关键的一条路

选型最怕纸上谈兵，我们花了一晚上验证最不确定的环节：前端能不能一行代码调到云函数。

# 新建一个云函数做认证演练
tcb fn init signin
tcb fn deploy signin

前端引入 SDK 后调用的代码极其短：

// 初始化SDK，填入自己的环境ID
app.init({ env: "my-app-env" });

// 直接调用云函数拿登录态
const res = await app.callFunction({
  name: "signin",
  data: { code: "test" }
});
console.log(res.result);

调通那一刻基本就拍板了：前端写法足够自然，后端逻辑又能完全自己掌控，这是 SaaS 给不了的体验。这件事在本书的SDK 接入一节有完整的落地步骤。

说干就干，当晚我们又顺手把发布图文的链路也验证了。前端拿临时密钥直传图片到对象存储，云函数负责写数据库记录，整条链路不到两百行代码。第二天合伙人把demo发到内测群，已经是一个能完整跑的产品雏形了。如果选 SaaS，同样的定制程度可能需要排队等厂商排期，或者干脆放弃。

趁热打铁又验证了权限这一环。云开发的数据库集合可以配读写权限，我们把文章集合设成所有人可读、仅登录可写，一行配置就顶上传统架构里半天的鉴权代码。权限怎么配最踏实，在集合权限一节有图文对照的说明，这里先点一句：权限模型选对，后面云函数能少写一半代码。

踩坑：SaaS 的坑我们替你踩过

虽然最后没选 SaaS，调研过程里三个教训值得记下：

第一是迁移成本。一个朋友把图文站建在某建站平台上，两年后想迁出来，发现只能一条条复制粘贴正文，图片还得手动另存。几百篇文章迁了一个月，最后放弃了。数据在自己手里这件事，平时不疼，疼起来要命。这也是我们选型时把数据可导出列为硬指标的原因：你永远不知道两年后的自己想做什么，别让平台替你做决定。

第二是隐藏费用。很多 SaaS 看起来月费便宜，但流量上去之后带宽费按GB另算，图片存储超量也加钱，一年算下来比云开发按量还贵。计费细则一定在掏钱之前看清楚，我们后来复盘费用时专门拉过费用与免费额度的对照来看。再就是功能分级，便宜的档位往往刚好缺你想要的那一个功能，逼着你升到贵的档。

第三是能力天花板。SaaS 平台的功能更新取决于厂商，你想要的一个小功能可能排队两年。云开发这边缺什么自己写个云函数就补上了，迭代节奏完全在自己手里。我们后来加的每日自动摘要是临时拍脑袋的需求，从想法到上线就一个晚上，这种自由度任何 SaaS 都不会提供。

第四是调试与排查。SaaS 出了问题只能提工单等回复，你拿不到日志也看不到完整链路。自己的云函数至少日志就在眼前，排查节奏自己掌握。这一点对技术型团队尤其重要。

小结

SaaS 适合没有定制需求、只想快速有个门面、用完即走的场景；一旦你的应用有自己的业务流程、想长期迭代、想把数据握在手里，就得回到代码层面。云开发恰好站在这个十字路口上：保留 Serverless 的省心，又给你完整的后端自由度。这也是为什么这本书接下来所有的章节都建立在它之上。

如果你也走到这一步还没决定，我给一个可照做的验证方法：花一个晚上把最不确定的那条链路用代码跑通，而不是继续做表格对比。我们就是这么拍板的，跑通代码带来的信心比任何对比表都足。

最后补一句关于预算的话：如果你手头紧，又恰好是新用户，开环境时记得先把试用额度和免费额度吃满，具体能撑多久在费用与免费额度一节有逐月账单复盘。我们的内测期就是这么零成本扛过来的。

方案定了，下一节先把钱包的事聊清楚：免费额度到底能撑多久，什么阶段开始需要认真对待成本。再往后的 1.4 节，就正式进入动手砍 MVP 范围、搭第一个界面脚手架的环节。

延伸阅读