前几天有个朋友问我AI 写代码速度这么快你怎么还在折腾服务器我愣了一下仔细想想还真对。让 AI 帮我写后端接口时Prompt 一给CRUD 接口十分钟就出来了前端页面也大差不差。可真到了把后端跑起来、让外网能访问这一步我还在干着十年前的老活儿买服务器、选镜像、配安全组、装 Nginx、传代码、重启进程。AI 替我加速了写代码却没能加速我把代码放到线上。后来我把整个后端搬到了腾讯云 CloudBase彻底告别了那套手工运维流程。这篇文章会把这次迁移的完整过程、改造思路和踩过的坑都写清楚包括为什么选 CloudBase、Express 后端怎么改成云函数、SQL 表怎么迁到文档型数据库、本地联调和跨域怎么处理以及我让 AI 帮忙干活时的提示词和它没帮上的地方。适合正准备用 AI 做个人项目、小程序后端或者想从传统服务器迁移到 Serverless 的同学参考。1. AI十分钟写完接口我却为部署耗了一天传统后端上线流程的槽点先说说我原来的状态。我手上有一个前后端分离的小项目后端是 Node.js Express数据库用的 MySQL文件上传走的是本机磁盘存路径。AI 帮我写完业务接口之后我的上线流程是这样的打开云厂商控制台买一台轻量服务器选好镜像通常还得重装一次系统把环境换对然后 SSH 登上去按照教程装 Node.js、pm2、Nginx再配环境变量、改安全组端口、把代码拉到服务器上、pm2 start。运气好两个小时能搞定运气不好踩到某个依赖版本问题一天就交代了。1.1 购买服务器、装环境、配Nginx我的时间都去哪了我算过一笔账AI 帮我写 20 个接口大概花了一个半小时。而我把它部署到服务器上花了整整一个下午。而且这种部署不是一次性的后续每次改完代码都要重新走一遍上传、重启、看日志、排查。要是服务器挂了或者进程崩了还得上去手动拉起。这个工作里的重复性极高又完全没法通过写代码本身来优化属于纯纯的环境债。传统服务器部署的痛点我总结成一张表和 CloudBase 放在一起对比会更直观环节传统云服务器CloudBase环境安装买机器、装 Node/Nginx/pm2、配系统变量直接创建云函数运行时环境平台自带发布流程SSH 上传、重启进程、人工盯状态CLI 一条命令部署自动构建容量管理买多大的机器就得用多大的闲置也花钱按调用量自动伸缩没调用时不跑计费模式包月/包年无论用不用都扣钱按量计费有免费额度适合个人项目运维压力7×24 小时看进程、防磁盘满、防宕机底层由平台托管主要看函数日志我当时决定迁移完全是因为被这个部署流程磨得没脾气了。但光有不想再折腾服务器的动力不够还得确认 CloudBase 适不适合我的项目形态。1.2 我判断该不该换Serverless的三个信号并不是所有项目都适合往 Serverless 上搬至少我身边有人硬搬之后反而更痛苦。我给自己定了三个判断信号都对上了才动手第一后端接口的调用频率是不是集中在某个时段整体不算高。我这个项目的日活就几百人接口 QPS 峰值也就几十属于典型的低频伸缩型负载。如果是一个需要几十上百个常驻实例才能扛住压的高并发服务Serverless 的冷启动和资源争用会让你很难受。第二愿不愿意接受按量计费的不确定性。传统服务器是固定开销钱数从买的那一刻就是死的。CloudBase 这种按调用次数、资源使用量、流量来计费的模式好处是大促没流量时几乎不花钱坏处是流量真上来时费用也会跟着涨。对我来说一个几千块的开发预算里这个波动完全可控。第三手上有一些项目是想快速验证想法的不想一次性投入大量时间在运维上。比如 AI 给我写了个新点子我想今天写出来、今晚就放到线上让别人访问传统服务器那条路根本走不通光是等环境就不知道要多久。三条都对上之后我没有立刻迁移而是先把 CloudBase 的运行模型彻底搞明白因为这个决策一旦做下去代码层是要跟着动的。2. CloudBase到底是个什么东西迁移前必须想清楚的运行模型我第一次接触 CloudBase 的时候下意识把它理解成云上的虚拟主机觉得就是一台帮我装好环境的服务器。这是最大的误区。CloudBase 不是一台机器而是一整套托管后端环境它把传统部署里你需要自己操心的那部分全部抽象掉了。2.1 CloudBase不等于一台云服务器它是一套托管后端环境CloudBase 的核心组件是四样云函数、云数据库、云存储、静态托管。云函数负责跑业务逻辑但你不需要知道它跑在哪台机器上云数据库是一个文档型数据库直接通过 SDK 读写省掉了自己搭 MySQL 的过程云存储用来放用户上传的文件避免自己管磁盘静态托管则可以放前端页面直接把前后端一起托管上去。我当时的需求是后端接口上云所以主要用到的就是云函数 云数据库 云存储。静态托管属于附带的红利后面我直接把前端也扔上去了省了一台 Nginx。2.2 搬家清单代码之外还有四样东西迁移之前我先列了个搬家清单发现要搬的不只是代码文件还有四样东西第一HTTP 路由层。我原来用 Express 写了很多/api/users、/api/orders这样的路由迁移后这些路由必须还能被前端通过同样的 URL 访问否则就得改前端代码工程量大增。第二数据持久化。原来 MySQL 里有一堆表和数据需要迁到云数据库里包括表结构设计、数据导入、查询逻辑改写。第三文件上传能力。用户头像、图片上传原来落在本机磁盘域名解析出去就能访问搬走之后要改用云存储的临时链接机制。第四环境变量和密钥。数据库密码、第三方 API Key、JWT 密钥这些原来写在服务器环境变量里迁过来要在云函数的环境变量配置里重新设置。这四样东西随便漏一样线上跑起来都会立刻报错。我见过有朋友迁完接口发现上传的图片全裂了就是因为只搬了代码没处理文件存储。2.3 从常驻进程到短生命周期函数运行模型变化理解 CloudBase 的云函数关键要理解它和传统后端进程的差别。传统 Express 应用启动之后会一直常驻在内存里监听端口进来一个请求处理一个进程不退出。云函数则完全不同它是事件驱动的没有请求进来的时候函数实例根本不存在每个请求进来平台才会把函数拉起、执行、返回结果随后进入待回收状态。这个运行模型带来的直接影响就是你在代码里不能假设进程是常驻的。比如全局变量存数据、进程内存里做缓存、启动时建立的长连接这些都要重新设计。我的项目里有些逻辑是启动时加载一份配置到内存里迁到云函数后就不能这么干只能每次请求都从数据库读或者自己实现一个简单的远程配置服务。把运行模型搞明白之后剩下的就是实操层面的改造了。3. 云函数改造实操把Express后端挂上CloudBase的HTTP访问服务整个迁移里最核心的一步就是让 Express 应用能在云函数里跑起来。这一步方案选对了后面会很顺选错了光是路由和请求上下文就能劝退你。3.1 初始化项目CLI安装、登录与创建环境CloudBase 提供了一套官方 CLI我用的工具链是cloudbase/cli。安装和初始化流程如下# 全局安装 CloudBase CLI npm install -g cloudbase/cli # 登录腾讯云账号会拉起浏览器授权 tcb login # 在项目根目录初始化 tcb inittcb init执行后CLI 会引导你关联已有的云开发环境或者新建一个。环境这个概念你要先理解透它就像传统项目里的一个部署空间包含独立的函数列表、数据库实例和存储桶。如果你同时有开发环境和生产环境迁移时注意不要把测试数据写到线上库里。初始化完成后项目里会生成一个cloudbaserc.json配置文件之后部署就用它来识别环境。我的建议是在正式写改造代码之前先用 CLI 里的tcb fn create随便创建一个 Hello World 云函数部署一次把整条链路走通。别一上来就急着改大项目环境都没通就折腾路由出问题你根本分不清是配置问题还是代码问题。3.2 改造Express入口让serverless-http接管我原来的后端入口是一个标准的 Express 应用长这样// app.js const express require(express); const app express(); app.use(express.json()); app.use(express.urlencoded({ extended: true })); app.get(/api/health, (req, res) { res.json({ status: ok }); }); // ... 其他路由 app.listen(3000, () { console.log(server running on 3000); });在 CloudBase 云函数里不能直接app.listen(3000)因为云函数不提供常驻端口。它的标准入口是导出一个main函数接收事件对象并返回响应。我一开始想自己手动解析事件把event.headers、event.body一个个拼成 Express 的req结果写出来又长又容易漏。后来直接用了一个库叫serverless-http它做的事情就是让 Express 应用能作为 Serverless 函数被调用// index.js const express require(express); const serverless require(serverless-http); const app express(); app.use(express.json()); app.use(express.urlencoded({ extended: true })); app.get(/api/health, (req, res) { res.json({ status: ok }); }); // ... 其他路由保持原来的写法不变 exports.main serverless(app);这段代码里有个关键的细节要记住不要把app.listen(3000)那段留着否则云函数跑起来会在同一份代码里既想监听端口又想去入口函数平台大概率会报错。改完之后exports.main就是新的入口Express 的所有路由逻辑和中间件机制都原样保留。依赖方面只需要在云函数的package.json里加上serverless-http这个依赖。部署时 CLI 会上传源码平台安装依赖后运行。3.3 配置HTTP访问服务让前端继续用 /api 路由代码改造完之后接下来做 HTTP 触发配置。云函数默认不能直接被外部 HTTP 请求打到需要先在 CloudBase 控制台或者配置里开启HTTP 访问服务也叫云接入把某个路径映射到云函数上。我的做法是设置触发路径为/api/{path}方法为ANY指向我新建的那个云函数。这样前端请求https://xxx.tcloudbaseapp.com/api/users时平台会把请求转发给云函数云函数内部由 Express 继续处理/api/users路由。前端代码里所有以/api开头的请求都不用改这一点对迁移帮助非常大。这里有个细节值得多说一句HTTP 访问服务转发给云函数的事件结构不同版本可能略有差异。如果你用serverless-http后发现req.body是空的或者路由req.path不对先别急着怀疑代码去云函数里把event整个打印出来看一遍确认字段名是path还是url、body是字符串还是对象。我见过很多人卡在这里其实是事件结构没对上。云函数改造完成后接着处理最麻烦的数据层。4. 数据库与文件存储搬家SQL表改成文档集合的实际差异我原来的数据存在 MySQL 里有用户表、订单表、内容表等十来张表。CloudBase 的云数据库是文档型数据库结构上已经不是表关系那一套了。这个转变对写过 SQL 的人需要一个认知切换。4.1 我的表结构迁移实例users 和 orders 怎么改先看一个具体例子。我原来的用户表结构大致长这样CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), email VARCHAR(100), created_at DATETIME );订单表CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, amount DECIMAL(10,2), status VARCHAR(20), created_at DATETIME );迁移到云数据库后表变成集合行变文档主键从自增id变成_id。_id可以是平台自动生成的字符串也可以自己指定。时间字段我改成了时间戳方便前端直接用。迁移后的集合设计大概是这样的MySQL 表CloudBase 集合字段变化说明usersusersid 删掉新增 _idcreated_at 改 createdAt文档主键用 _idordersordersid 删掉新增 _iduser_id 保留为 userId外键关系保留为普通字段关联查询靠代码完成文档型数据库里没有 SQL 的 JOIN。我之前写习惯了一行SELECT orders.*, users.name FROM orders JOIN users ON orders.user_id users.id到云数据库里就得手动拆成两次查询先查订单再根据 userId 批量查用户信息。这是迁移时语法上最容易不习惯的地方。4.2 用cloudbase/node-sdk读写文档型数据库云函数里操作云数据库用官方 SDK包名是cloudbase/node-sdk。在云函数里可以直接初始化当前环境的数据库实例不需要往代码里塞数据库密码const cloudbase require(cloudbase/node-sdk); const app cloudbase.init({ env: cloudbase.SYMBOL_CURRENT_ENV }); const db app.database(); exports.main async (event) { // 查询用户 const userRes await db.collection(users) .where({ email: testexample.com }) .get(); // 新增订单 const addRes await db.collection(orders).add({ userId: userRes.data[0]._id, amount: 99.5, status: pending, createdAt: Date.now() }); return { code: 0, data: { orderId: addRes.id, user: userRes.data[0] } }; };这套 API 的学习成本不高核心就几个方法collection().where().get()查数据collection().add()增数据.doc().update()改数据.doc().remove()删数据。分页和排序用orderBy、limit、skip配合写起来比 SQL 直观但性能优化的思路不太一样索引要自己在控制台里建不能靠 SQL 的执行计划。4.3 用户头像等文件上传迁移到云存储文件上传是我原来依赖本机磁盘最重的一个模块。原来用 multer 接收文件存到服务器某个目录然后把静态路径返回给前端。迁到 CloudBase 后我改成了云存储方案客户端先上传文件到云存储拿到一个 fileID再把 fileID 传给后端接口由后端把这个 ID 写入数据库。云函数里如果需要在服务端接收文件流再上传可以用 SDK 的uploadFileconst cloudbase require(cloudbase/node-sdk); const app cloudbase.init({ env: cloudbase.SYMBOL_CURRENT_ENV }); exports.main async (event) { // event.fileBase64 是前端传来的 base64 文件内容 const res await app.uploadFile({ cloudPath: avatar/${Date.now()}.png, fileContent: Buffer.from(event.fileBase64, base64) }); // 获取临时访问链接 const { fileList } await app.getTempFileURL({ fileList: [res.fileID] }); return { code: 0, data: { fileID: res.fileID, tempUrl: fileList[0].tempFileURL } }; };一个很细节的点云存储的临时链接是有有效期的默认很短不能像以前静态目录里那样永久挂在img src上。如果业务需要长期展示用户头像要么后端定期刷新链接要么前端拿到链接后用于短期展示长期存储还是用 fileID。我第一次迁移时没注意这一点第二天用户头像全裂了排查半天才发现是临时链接过期这个坑写出来希望你能避开。数据层搞定之后我一度觉得自己已经迁移完成了。结果本地一跑立刻被跨域问题拍了一巴掌。5. 本地联调与跨域迁移过程中最容易劝退的两道坎5.1 本地调试CloudBase CLI的本地开发体验我在迁移之前最担心的一个问题就是本地怎么调试。以前改完 Express 代码npm run dev直接监听本机端口浏览器里马上能试。迁移成云函数之后总感觉每一行代码都要部署到线上才能验证那效率太低了。实际上 CloudBase CLI 提供了本地开发模式印象里在项目根目录跑一个命令就能把云函数、数据库、存储都在本地模拟出来tcb dev它会拉起来一个本地服务云函数里的代码会被监听文件变化自动热更新本地的访问路径尽量保持和线上一致。这样我调试接口时还是像以前一样用 postman 打http://localhost:xxxx/api/xxx只不过代码的组织方式从整个应用启动变成了云函数入口被触发。不过本地开发环境到底有多完整不同版本 CLI 有差异。我的建议是关键逻辑写完先用本地模式跑通但不要完全依赖它最终以部署到线上后的真实表现为主。因为本地环境在鉴权、安全规则、事件结构上仍然可能和线上有细微差别遇到环境相关的问题最快的排查方式还是直接把函数部署上去看日志。5.2 跨域问题为什么本地localhost调线上接口会失败本地开发跑通了前端一接线上地址问题来了。我前端跑在localhost:5173线上接口是https://xxx.tcloudbaseapp.com/api/xxx浏览器直接报 CORS 错误。这个问题的本质是浏览器的同源策略请求的域名、协议、端口只要有一个和当前页面不一样浏览器默认会拦截响应除非服务端明确告诉它我允许你这个来源跨域访问。解决方式是在云函数返回响应的时候加上跨域允许的响应头并且处理一下 OPTIONS 预检请求。我在 Express 里加了一段全局中间件app.use((req, res, next) { res.set(Access-Control-Allow-Origin, *); res.set(Access-Control-Allow-Methods, GET, POST, PUT, DELETE, OPTIONS); res.set(Access-Control-Allow-Headers, Content-Type, Authorization); if (req.method OPTIONS) { return res.status(204).end(); } next(); });这段代码里Access-Control-Allow-Origin我开发时图省事设成了*正式上线前建议改成自己前端域名的白名单而不是全开放不然别人网站直接就能调你的接口。另外如果你的请求里带了自定义请求头比如Authorization记得在Access-Control-Allow-Headers里显式声明否则预检请求照样不过。5.3 密钥管理环境变量与数据库安全规则迁移过程中我特别关注一件事以前服务器上那些密钥到底放哪儿。我见过有人把数据库密码、云 API 密钥直接硬编码在云函数代码里这是很危险的习惯。CloudBase 云函数的配置项里可以直接设置环境变量代码里保持干净只用process.env去读取const jwtSecret process.env.JWT_SECRET;这个JWT_SECRET在控制台的云函数配置里填好不要提交到 git 仓库。本地开发时如果也要跑我就在本地.env文件里配一份但确保它被.gitignore忽略。数据库安全规则也要顺手理一遍。云数据库默认的权限通常比较严格但如果你开发时为了图方便给集合开了公共读权限迁移到生产环境就等着被刷流量吧。我的做法是所有数据读写都走后端接口由云函数使用管理员权限访问数据库前端不直接访问云数据库集合的访问权限设置成只允许后端经过鉴权后访问防止绕过接口直接读数据。联调和跨域问题解决之后我的后端基本已经跑通了。剩下的一个疑问是整个迁移过程里 AI 到底能帮我到什么程度。6. 让AI参与这次迁移提示词、有效产出和它没帮上的忙既然一开始是因为用 AI 写代码才攒下这么个项目迁移时我自然也想尽量让 AI 多干点活。实际用下来AI 能帮上忙的地方确实不少但也有一些事情它完全搞不定需要自己拍板。6.1 我实际用过的三段AI提示词可复制第一段是让它按 CloudBase 的规范改写代码。我用的是这个思路的提示词我有一个 Express 后端应用入口文件长这样贴代码。现在要把它改造成腾讯云 CloudBase 云函数的写法要求使用 serverless-http 转换入口保持原有路由路径不变main 函数导出的返回值格式符合云函数规范。请给出改完之后的完整入口文件和相关依赖改动。这段提示词的效果非常好因为我把上下文给足了AI 只需要做机械的迁移不需要自己假设项目结构。第二段是数据库迁移设计。我贴了原有的建表 SQL然后问以上是 MySQL 建表语句。请帮我迁移到文档型数据库给出每个集合的字段设计建议说明哪些字段需要建索引并针对常见的 JOIN 查询给出改造成文档查询的示例。它会很自然地提醒你原来是外键的字段现在保留成普通字段并且会针对orders和users的关联查询给出两次查询的方案。第三段是踩坑之后的反问。我遇到 CORS 问题时直接问前端在 localhost:5173接口在 https://xxx.tcloudbaseapp.com/api浏览器报 Access-Control-Allow-Origin 错误。我的云函数里跑的是 Express 和 serverless-http帮我排查并给出修复代码。这种问题描述得越具体AI 给的答案越准。千万别只丢一句跨域报错怎么办它答出来的大概率是最泛的教程。6.2 AI没帮上忙的三件事冷启动、计费估算、安全规则先说冷启动。云函数在没有请求时处于休眠状态下一个请求进来需要冷启动时间通常比常驻进程要长。AI 不会替你做这个判断你的业务能不能接受偶尔几百毫秒的冷启动延迟我迁移完之后发现像查询数据库这种重一点的请求本来就要几十毫秒加一个冷启动时间完全无感。但对于那种对响应时间极敏感的业务可能要提前做常驻实例配置这个决策得人来定。第二件是计费预算。AI 不会看你的账单也不了解项目的调用量。我在迁移前自己粗略估算过假设日活 500 人人均调用接口 20 次一个月大概 30 万次调用每次运行 100 毫秒对应多少资源使用量再对比免费额度和按量价格。这个算术题你自己不算清楚后面收到账单会慌。第三件是安全规则。AI 给出的示例代码为了让你跑通测试经常是能跑就行的逻辑比如把集合的权限设得非常宽松。我在调试阶段确实图省事开过一阵子公共读权限后来上线前专门把所有集合的安全规则重新收紧了一遍确保每一个数据库访问都来自经过鉴权的云函数。这种事 AI 不会主动提醒你生产环境要用什么权限策略。6.3 搬完一个月后的体验我后悔的是没早点迁迁移完成到现在跑了大概一个月我说说真实感受好的坏的都有。好的方面部署流程变短了改完代码后一条命令部署不用再 SSH 上去重启进程成本确实下来了项目的调用量在基础免费额度范围内基本不额外花钱存储这块用户上传文件再也不用担心磁盘满。最直接的体感是我敢随手开新项目了反正部署一个云函数的成本很低不用像以前那样开个新项目先纠结要不要花几十块钱买服务器。不太好的方面也有云函数日志查看和控制台操作流畅度比传统服务器上直接看 pm2 日志还是差一点文档型数据库做复杂报表查询会很累我这边有一个统计分析的需求最后是单独拉数据回本地算的冷启动偶尔还是会遇到但我通过控制台把常用函数的内存调高、尽量复用实例之后体感改善了很多。如果现在有朋友问我在腾讯云 CloudBase 上做个人项目后端值不值我会问他你愿意花一个下午装环境还是花一个下午把代码改成云函数前者换来的是熟悉的服务器后者换来的是以后每次上线的轻松。我自己选了后者而且说实话我最后悔的是没有更早一点搬过来。