1. Leancloud 到底是什么为什么会被叫作“平价可爱”1.1 初学者的第一个“云后端”说实话看到 Leancloud 停服公告的那一刻我心里一半是早有预感一半是确实难受。对一个从大学时代就用它写课程设计、写毕设、写各种练手 Demo 的人来说它不只是个后端服务更像是我编程路上的第一张“免费工位”。如果你没用过我先用一句话说清楚Leancloud 是国内最早一批做 BaaSBackend as a Service后端即服务的云服务平台你不需要买服务器、不需要配 Nginx、不需要手动管理数据库注册一个账号前端代码里引一行 SDK就能立刻拥有一个带用户系统、数据存储和推送通知的后端。当年它还叫 AVOS Cloud 的时候我是在一篇“用云服务做一个 App 后台”的教程里认识它的。说实话那篇教程写得一般但“不用买服务器就能做 App 后端”这句话对一个穷学生来说太有吸引力了。后来它改名成 Leancloud中文文档越写越顺手社区里的例子也越来越多课程设计、社团活动报名、毕业设计我身边一半同学的练手项目都是它撑起来的。对当时的我们来说它就像那个“平价又可爱”的选项便宜到几乎没有门槛界面配色清爽文档里好多地方都带示例代码连报错信息都比别的平台温柔一点。用现在的话说它就是开发者工具里的“入门友好型产品”。1.2 那套免费额度是真的在替开发者着想我记得当时的开发版是免费的每天有请求次数和存储空间限制但你正常做个课程设计、写个小工具、跑一个几百人的活动报名完全够用。它没有像一些平台那样搞“新用户注册领多少额度、过期清零”而是给了长期稳定的免费档位这一点就非常良心。更重要的是Leancloud 把“后端”这个概念拆成了一个个看得懂的模块。你不需要一开始就理解负载均衡、反向代理、数据库连接池只需要知道我有一个表里面存数据我有一个函数可以被前端调用。这种思维上的降级恰好踩中了新手最需要的那一步——先建立“我能写出完整应用”的正反馈再去补底层原理。免费额度背后其实有一套很精巧的考虑BaaS 的边际成本主要来自存储、流量和计算资源个人开发者用量低成本可控等这批人毕业进了公司、或者自己的产品跑起来自然会成为付费客户。这个算盘本身没问题只是后来一些事情让这条路走不下去了后面我会专门说。2. 从功能拆解看它为什么能留住人2.1 数据存储把“数据库”装进口袋Leancloud 的核心是它的数据存储服务官方叫 mStorage。你不需要写建表 SQL不需要维护数据库直接在控制台创建 Class可以理解成一张表然后用 SDK 往里写 JSON 对象就够了。举个我当时最常写的例子const AV require(leancloud-storage); AV.init({ appId: 你的AppId, appKey: 你的AppKey }); // 定义一个“消息”类 const Message AV.Object.extend(Message); const message new Message(); message.set(content, 大家好这是我的后端); message.set(author, 张三); message.set(likes, 0); await message.save();存进去之后查询也是 SDK 内置的不用拼 SQLconst query new AV.Query(Message); query.equalTo(author, 张三); query.descending(createdAt); const list await query.find(); list.forEach(item console.log(item.get(content)));那时候的我觉得这简直像变魔术。后来才明白它其实就是把 NoSQL 的存储模型包装成了“对象”让你像操作本地变量一样操作云端数据。这种设计的价值不在于多高级而在于第一次让你摸到了“前后端联调”的真实手感数据存得进去、查得出来接口调得通一个完整的链路就在眼前。但也要承认这个便利是有代价的。由于不需要设计表结构很多初学者包括我会把数据存得乱七八糟字段命名随意、嵌套层级很乱、该关联的数据没有用 Pointer 关联。到迁移的时候这些“欠债”都变成了要还的账。2.2 云引擎前端同学也能碰后端除了数据存储Leancloud 的云引擎也是一绝。它提供了一个 Node.js 运行环境你可以直接在上面写云函数前端通过 SDK 调用。举个例子AV.Cloud.define(getUserInfo, async (request) { const userId request.params.userId; const user await new AV.Query(_User).get(userId); return { nickname: user.get(nickname), avatar: user.get(avatar) }; });前端调用就是一行const result await AV.Cloud.run(getUserInfo, { userId: xxx });对一个以写前端为主的人来说这相当于第一次亲手碰“后端逻辑”又不用理解服务器部署、不用学 Linux。更重要的是云引擎还能挂定时任务比如每天凌晨统计一次日活、每周清理一次过期数据。我当时花了一个下午搞定了一个“每日签到统计”的定时任务成就感是实实在在的。现在回头看云引擎在技术上不复杂但它做对了一件事把“后端开发”的门槛从“需要了解整个运维体系”降到了“会写一个函数”。这个思路后来被所有 Serverless 产品复制了所以 Leancloud 其实算得上是中国 Serverless 概念的早期布道者之一。2.3 用户系统、推送、短信这些“小零件”的大意义Leancloud 还自带一堆开箱即用的小模块单看每一个都不起眼组合起来却是一个完整 App 后端的“最小闭环”。用户系统是我用得最多的。AV.User 帮我把注册、登录、会话管理全封装好了const user new AV.User(); user.setUsername(test); user.setPassword(123456); await user.signUp(); // 之后每次操作SDK 会带上 sessionToken那时候我完全不知道 session、cookie、Token 这些概念但代码居然能跑通。后来做项目遇到需要自己写登录的时候才回头补这些知识。这也是 Leancloud 这类平台的共同特点让你先“用起来”再用到某个深度后自然会去想“它是怎么实现的”。推送、短信验证码、实时数据订阅也都是类似逻辑。比如发送短信验证码一条 SDK 方法就搞定了不用去对接运营商的接口。很多刚入门的人以为这些功能“很难”其实只是没接触过——而 Leancloud 的价值就是把这些“以为很难”的东西变得伸手就能够到。3. 它为什么会走到停服这一步3.1 免费策略与商业化的矛盾先说一个最直白的现实BaaS 本质上是一门“资源生意”存储、带宽、计算都是真金白银的成本而它的用户群又恰恰是对价格最敏感的人群。个人开发者习惯了免费额度很难转化为付费用户真愿意付费的企业用户要求又多私有化部署、定制功能、SLA 保障、合规审计每一项都是成本。这就让独立 BaaS 平台陷入了一个两难对个人收钱会把好不容易攒起来的口碑打掉对企业放弃又撑不起营收规模。说白了就像开了一家平价食堂学生顾客越来越多但菜价不能涨、租金一直在涨你还得另外开小灶去伺候能付得起钱的企业客户——两头都不容易讨好。我之前和一些做开发者工具的团队聊过他们的共同感受是做开发者服务的“品牌好感度”很容易积累但“盈利能力”非常难验证。尤其是当用户习惯了“免费 好用”你一旦把某些功能放到付费墙后面舆论压力会立刻涌上来。Leancloud 这么多年能保持免费档位不死已经算很克制了。3.2 大厂云生态的挤压第二个原因是行业格局变了。最近几年各个云服务大厂纷纷把“云函数 云数据库 对象存储 短信服务”打包成产品线新用户注册还送一堆长期或短期额度。对普通开发者来说在大厂一套体系里能搞定的事没有理由拆到好几个平台去做对一个公司来说也更倾向于把云资源统一在一个供应商下方便开票、审核和运维。在这种挤压下独立 BaaS 的差异化壁垒几乎消失。过去大家选 Leancloud是因为它“小而美、中文文档好、专门做后端服务”但当大厂用生态优势把同类功能做到近乎免费时“小而美”就变成了“小而贵”或“小而难以维持”。开发者是实际的使用者离开的时候虽然说一声“可惜”但身体很诚实。还有一个容易被忽略的变量开源社区。Supabase、Parse Server 这类开源项目让“自托管一个 BaaS”变成了可能开发者发现自己也可以拥有一套可控的、不会停服的平替。当“用别人的服务”和“用自己部署的服务”之间的差距越来越小独立云服务平台的生存空间就被两头夹住了。3.3 停服公告之后的普遍难题停服这件事最难的不是“不能再用了”而是“存量用户怎么办”。我身边受影响的人大致分三类做着玩的小项目直接弃坑数据导出来留个纪念产品下线。正经在运营的小产品必须在窗口期内完成数据迁移、域名切换、推送重配相当折腾。还处于学习阶段的新手突然发现教程里的平台没了学习的路径被打断。对第二类人来说停服通知里通常会给一个明确的时间节点要求你在那之前把数据导走。真正的问题是很多人的产品已经上线很久数据格式、代码逻辑、第三方配置全都深度绑定了平台提供的特性迁移不是“复制粘贴”能搞定的。这也是所有“平台依赖症”的最终代价——你享受了多少便利就得在告别时付出多少对应的心力。从行业影响来看这次停服更像一个信号纯独立 BaaS 的商业模式已经越来越难走未来开发者能依赖的“省心后端”要么来自大厂的生态要么来自自己掌握全套数据的开源方案中间层的空间会越来越窄。4. 停服前我做的迁移实操记录4.1 第一步把数据完整倒出来停服公告出来后我第一时间做的事不是唉声叹气而是把所有数据从控制台和 API 两头分别导了一份。这里有个建议不要把“第一次导出”当作“唯一一次导出”先做一轮完整备份再边改代码边增量导出最后停服前再做一次兜底三重保障。我写了一个 Node.js 脚本用官方 SDK 按 Class 逐个导出。关键的注意点是如果没有特殊要求尽量把时间戳、ACL、Pointer 关系这些“元信息”一起带出来。下面是我当时的做法你参考着改就行const AV require(leancloud-storage); const fs require(fs); AV.init({ appId: process.env.APP_ID, appKey: process.env.APP_KEY }); async function exportClass(className) { const items []; let lastCreatedAt new Date(0); // 按 createdAt 增量翻页 const pageSize 500; while (true) { const query new AV.Query(className); query.greaterThan(createdAt, lastCreatedAt); query.ascending(createdAt); query.limit(pageSize); const list await query.find(); if (list.length 0) break; items.push(...list.map((obj) obj.toJSON())); console.log(${className}: 已导出 ${items.length} 条); lastCreatedAt list[list.length - 1].get(createdAt); if (list.length pageSize) break; } fs.writeFileSync(${className}.json, JSON.stringify(items, null, 2)); } exportClass(Message).catch(console.error);这里用greaterThan(createdAt, lastCreatedAt)而不是skip分页是因为停服前夕很多人都在写数据skip分页容易漏数据、也容易重复按时间游标翻页更稳。导出完成后我先把每个 Class 的总条数记下来后面增量导出的时候可以对得出有没有缺漏。4.2 第二步选迁移目标数据拿到手之后就要考虑迁到哪去了。我自己当时对比了几个方向这张表你可以直接收藏方案代表适合谁门槛备注大厂 Serverless 全家桶云函数 云数据库 对象存储想在自家云生态里省事中等免费额度后按量付费开源 BaaS 自托管Supabase、Parse Server想掌控数据、愿意学点运维偏高一台小服务器就能跑传统后端重写Node/Python MySQL/PostgreSQL本来就要做大的重构较高最可控成本最高我的选择是 Supabase它本身是 Postgres支持 SQL 和 REST 两种查询方式自带用户系统和存储还允许部署在自己的服务器上——就算再遇到类似情况也不至于手忙脚乱。更重要的是SQL 是通用标准以后想换到任何一家云数据库都容易。4.3 第三步改造代码保数据迁移不只是“把 JSON 文件搬到新库”中间要做几件具体的事第一数据模型转换。Leancloud 的 Class 和 JSON 结构对应到 Postgres 就是表需要把嵌套对象拆开或者用 JSONB 类型存住一时拆不开的字段。我当时的原则是能拆成列的就拆成列拆不动就用 JSONB尽量保留原始 JSON 作为兜底字段万一后面发现丢了什么东西还能捞回来。第二类型还原。Leancloud 导出的 JSON 里日期、指针、地理坐标都有特殊标记比如日期会变成{ __type: Date, iso: 2022-01-01T00:00:00.000Z }。导入新库前要写一个转换脚本把这些标记还原成新库对应的 datetime、外键、经纬度类型这一步最容易悄悄丢数据。第三用户系统替换。Leancloud 的AV.User和新平台的用户体系不是一套老用户的密码也没法直接迁移常见做法是让老用户走一次“重置密码”流程或者用邮箱/手机号作为唯一标识重建用户。我当时选了重置密码方案产品和用户都能接受。第四云函数与定时任务重写。所有AV.Cloud.define的代码都要移植到新平台的函数服务或者自己的服务里定时任务重新创建一个不复杂但时间表达式要仔细核对一遍。第五推送和短信重新配置。新平台需要重新申请推送通道、配置签名和证书短信模板也要在服务商后台重新审核。这些事项很碎建议建一张事项清单逐项打勾。5. 迁移过程中那些坑与排查实录5.1 导出文件打开乱码、格式不标准第一个坑是导出的文件根本不是标准 JSON 数组而是“一行一个 JSON 对象”的 NDJSON 格式。用编辑器直接打开如果对象里有特殊字符很可能显示乱码或者卡死。解决办法是别用编辑器硬扛写个小脚本逐行解析const fs require(fs); const lines fs.readFileSync(Message.json, utf8).split(\n).filter(Boolean); const rows lines.map((line) JSON.parse(line)); console.log(rows.length);如果文件特别大建议用jq这类命令行工具先抽样检查几条再决定要不要全量处理。我吃过一次亏一根筋把一个大文件直接加载进内存笔记本风扇狂转十分钟最后进程崩了白跑一趟。5.2 日期、指针、Geo 点的类型还原第二个坑就是上面提到的类型标记。数据导出来是一回事导入新库是另一回事。如果你的数据里有Pointer说明 Class 之间存在关联关系导入顺序要先解析出所有外键的指向关系才能保证导入后数据之间没有断链。我的踩坑经验是日期类型先转换成 ISO 字符串再由目标数据库解析成时间类型。指针类型记录好classNameobjectId的映射导入主表后再回填外键。地理位置保留经度纬度两个字段即可新库的 PostGIS 或普通point类型都能处理。这个环节是最容易“数据不报错但语义错误”的地方比如时间全都变成null、外键全断掉表面上看着导完了实际上一查询就露馅。所以我强烈建议导入完成后用原来的数据量做一轮总行数核对再抽样几条记录逐字段人工对比。5.3 文件域名与推送配置过期第三个坑是文件存储。Leancloud 的文件会有一个专属域名停服后这个域名大概率也会失效。如果你早期把文件 URL 直接存进了数据表而不是存文件 ID 再拼接 URL迁移的时候就要花大力气替换所有 URL 前缀更稳妥的做法是先把文件全部下载到本地或对象存储再在数据里换成新地址。这个操作听着简单真做起来会非常耗时尤其图片多的时候。推送和短信的配置也要重新弄。尤其是推送不同的应用商店要求的厂商通道配置不同新平台注册之后要重新绑定证书和密钥光这一步我就对着一堆配置文件折腾了大半天。这类工作不涉及什么高深技术但非常琐碎唯一有效的办法就是把所有步骤写进清单逐项确认别信自己的记忆。6. 告别之外小白怎么选“下一个后端”6.1 大厂云开发与 Serverless 阵营如果你现在是一个新手想找 Leancloud 的替代品我会先按你的目标来分。如果你的目标是让一个 App 或小程序快速跑起来、不想碰运维那么大厂云开发会是比较顺手的选项。它把数据库、存储、云函数和登录能力集成在一起很多能力甚至比当年的 Leancloud 更丰富免费额度也够初学者折腾。要注意的是这类服务本质上是“生态绑定”。你选择了它的数据库、登录和函数运行时就意味着以后迁移的门槛也不会低。这和当年选择 Leancloud 并没有本质区别只是把“停服风险”换成了“生态转换成本”。6.2 开源 BaaS 阵营如果你想从根上解决“平台停服”这件事我会推荐开源 BaaS。Supabase 和 Parse Server 是比较成熟的两个选择前者基于 Postgres上手之后能顺便把 SQL 学好后者几乎是 Parse 和 Leancloud 风格的后继者结构上很接近迁移思路也能复用。你只需要一台最便宜的云服务器用 Docker 把服务跑起来数据就真正在你手里了。对应的代价是运维系统更新、磁盘备份、宕机恢复都要自己负责。但换个角度想这也是值得的学费——学会这些你的能力边界就超过了“会用某个平台”的程度。我身边很多同事后来复盘都觉得这种“被逼着学运维”的经历反而是成长最快的一段。6.3 我的三点选型建议无论选哪条路我有三点建议想送给正在看这段的你第一给你的代码加一层“屏蔽层”。不要把 SDK 的调用散落在业务代码里哪怕只是简单包一层dataService、pushService在迁移的时候也能省下海量工作量。第二从第一天起就写备份脚本。不用很复杂定时把数据库导出到本地或对象存储就够了。你永远不知道平台什么时候会通知你“下个月停服”。第三优先选“数据能导出成通用格式”的平台。JSON、SQL、CSV 都行只要数据能出来迁移就有出路。最怕的是平台把数据锁死在自家私有格式里那才是真正的走投无路。我在这次迁移里最深的体会是工具会换平台会停但你真正学到的东西不会丢。当年在 Leancloud 上学会的前后端联调、数据建模、定时任务换一个平台照样能用反而是当年偷懒没学的那部分——比如备份、迁移、底层原理——这次被现实狠狠补了一课。如果你现在也用着某个云服务哪怕它再“平价钱可爱”也请记得定期把数据握在自己手里。这也是我写这篇记录的原因纪念一个老朋友也提醒后来的自己。