2.1 创建环境：入门 CloudBase 控制台

选型会后第一个周末，我们决定正式开工。第一个任务说起来简单：把云开发环境跑起来。但真坐到电脑前才发现，控制台里术语满天飞，环境、套餐、环境 ID、静态托管域名，每一步都要做选择，而每个选择背后都是钱和返工的成本。这一节把我们从零到第一个可用环境的完整路径记下来，包括填错的两个地方和后来怎么补救的。

场景：一个人要搞定一架服务器

我的需求很具体：项目就两个人，前端在本地跑，后端逻辑准备写云函数，图片放对象存储，数据库用来存文章和用户。传统做法里，这四件事分别对应四套配置：买机器、开数据库实例、开存储桶、配域名。而在云开发里，它们应该被一个东西打包掉，这个东西就是环境（Environment）。

环境是云开发里的一等公民：一个环境内置了文档型数据库、对象存储、云函数、静态托管和日志能力，彼此之间天然打通。这一点对独立开发者极其友好——你不需要在四个控制台之间来回跳，也不用操心它们之间的网络打通问题，因为它们从设计上就在同一个笼子里。

我们当时定的目标是用一个晚上完成三件事：创建环境、跑通 CLI、写一个 hello 函数验证整条链路。

方案：先控制台后 CLI

官方提供了两条入口：网页控制台和命令行工具。我们的做法是两条都走：先在控制台把环境实体建出来（涉及套餐选择，网页上看得清楚），再用 CLI 在本地把代码链路接上（日常开发不可能一直开浏览器）。这也可以参考腾讯云实践里其他项目的习惯：重决策走控制台，高频操作走命令行。

下单这一步顺带说一下费用。云开发有免费额度，图文项目早期基本烧不掉，本书目录第一章算过这笔账。新用户走活动页开通更划算一些，我们当时用的是这个入口：https://cloud.tencent.com/act/cps/redirect?redirect=3996&cps_key=2886aaf7fd441c23ba682c6fda7a9aff&from=console ，比控制台原价开通多送了一些额度。

控制台实操：八分钟建出环境

登录后左侧菜单进云开发控制台，点新建环境，重点填这几项：

填写项 我的取值 说明
环境 ID my-app-prod 全局唯一，CLI 里要用，建议带项目名
环境名称 图文分享正式环境 给人看的，随便起
套餐 基础版（含免费额度） 早期足够，不够再升
计费方式 按量付费 包年包月对低流量项目不划算
地域 广州 离目标用户近，南北差异明显

地域这一行我多想了一层：图文列表接口对延迟敏感，存储和函数的地域跟数据库一致，能避开跨区域访问。如果你的用户集中在北方，换北京地域；不纠结这点延迟的话选离自己最近的也行，调试快。

套餐选择也 worth 多说两句。云开发的套餐分几档，差的是并发实例数、云函数调用频率上限和数据库连接数。基础版对图文项目早期的几十 QPS 绰绰有余，等到日活破万再考虑升档，提前为用不到的配额付钱是最常见的浪费。我们项目上线八个月才第一次升档，而当时唯一触发升档的原因是图片处理函数的并发实例不够用。

点确定后大约一两分钟，环境状态变成运行中，数据库、存储、云函数、静态托管的入口就全部点亮了。这个时候别急着走，先进数据库页面看一眼，确认默认有几个系统集合存在，这是后面数据表设计要打交道的地方。

创建环境的完整流程顺手整理成一张核对表，第一次操作时照着走不会漏：

步骤 动作 易错点
1 想好环境 ID 并查重 建后不可改，别随手填
2 选地域 与目标用户群一致
3 选套餐 早期基础版即可
4 选计费方式 低流量选按量
5 建完进数据库面板确认集合入口 顺便检查教程示例是否可见
6 记录环境 ID 到项目 README 方便两周后回来看

CLI：把环境接到本地

控制台能做的事，CLI 基本都能做，而且能写进脚本和 README。安装与登录：

# 全局安装命令行工具
npm install -g @cloudbase/cli
# 浏览器扫码登录腾讯云账号
tcb login
# 看看刚才建的环境在不在
tcb env list

env list 输出里能看到环境 ID 和状态后，在项目目录初始化函数并部署：

# 初始化一个云函数（注意选择环境）
tcb fn init hello
# 部署到云端
tcb fn deploy hello
# 本地直接调用验证
tcb fn invoke hello

配合静态托管，前端目录也可以一条命令推上去：

# 把 dist 目录托管到环境自带域名下
tcb hosting deploy ./dist -e my-app-prod

跑完这三组命令，环境、函数、托管就全通了。那一刻合伙人发来消息：咱的服务器呢？我说：没有服务器，这就是全部。这种心情在第一次用 Serverless 时特别强烈，云函数入口的完整用法可以看后面的云函数创建一节。

本地开发时还有个小技巧：把环境 ID 写进环境变量而不是硬编码，切换正式与测试环境时只改一处：

# 项目根目录 .env 文件
TCB_ENV_ID=my-app-prod
# 部署脚本里读取
tcb fn deploy hello -e "$TCB_ENV_ID"

这一步看着多此一举，实际上线后切换环境全靠它，配合 git 分支管理测试环境与正式环境，Deploy 出错时回退也清晰。前期省下来的两分钟，后期不知道救多少次加班。

踩坑与排查

坑一：环境 ID 不能改。 我一开始随手填了个 test001，后面所有 CLI 命令、SDK 初始化、脚本里都绑死了这个 ID，正式上线想改名时发现改不了，只能重建环境再把数据迁过去。教训：环境 ID 当成域名来对待，上线前一定想清楚。

坑二：环境之间不共享数据。 后来建了个 test 环境做灰度，发现正式环境的集合、函数、存储桶在 test 环境里全都看不到，需要各自部署一遍。这不是 bug，是设计：环境就是隔离边界。脚本要写成参数化的，方便一键铺到多环境：

# 用 -e 参数指定目标环境
tcb fn deploy hello -e my-app-test
tcb fn deploy hello -e my-app-prod

坑三：CLI 版本与控制台不同步。 有阵子控制台已经支持新格式，旧版 CLI 部署时偶发报错，排查了半小时才发现是版本问题。遇到不认识的报错先 tcb -v 看版本，再 npm update -g @cloudbase/cli 升级，这一步能省掉大半排查时间。

坑四：免费额度是按环境的。 以为开了两个环境共享一份免费额度，实际是各自独立计费，两个环境同时跑测试流量，费用提醒翻倍。测试环境用完及时停，或者干脆删掉。

坑五：登录态串号。 同一台电脑上 tcb login 切换账号后，本地项目还缓存着旧账号的私钥，部署上去的函数归属错账号，控制台里死活找不到。清掉 ~/.cloudbase 下的登录缓存重新登录即可。多人共用一台机器时更容易踩，建议人手一个账号各登录各自的。

坑六：静态托管刷新慢。 部署完前端页面，浏览器里看到的还是旧版。托管默认带 CDN 缓存，强刷没用，需要在控制台手动刷新cdn缓存，或者部署时加版本号路径。后来我们把静态资源文件名都带上 hash，彻底绕开缓存问题。

坑七：函数默认超时不够用。 hello 函数毫秒级返回没感觉，等图片处理函数上线，默认三秒超时常常打不断，偶发超时告警。环境创建后建议先统一调整函数超时与内存默认值，别等告警了才一个一个改。函数运行参数调整在云函数面板的函数配置页，几秒钟的事。环境里还有一个小开关值得注意：云函数默认内存较低，图片压缩类函数跑起来吃力，按函数逐个调内存比全局加钱聪明。

小结

一个晚上，环境建好、CLI 跑通、函数验证完毕，传统架构里这一步至少是一天起步。关键操作就两条：控制台新建环境（想清楚环境 ID 和地域），CLI 接管日常部署。返工都出在不经大脑的默认值上，把上面表格里的五项填对，后面整本书的操作都能丝滑接上。

另外强烈建议环境建好后立刻把环境 ID、地域、套餐写进项目的 README，新人接手或者自己隔两周再回来时，这是最快的热身材料。如果你是从灯塔站点实战那条路线过来的，会发现控制台逻辑高度相似，迁移成本很低。

延伸阅读