免费额度这东西，签的是配额，不是性能承诺。小程序云开发数据库尤其典型——刚上手那阵子读写很顺，控制台里的额度条几乎不动，等到用户一多、列表页一刷，账单和报错差不多同时到。见过太多人把它当成「送的 MySQL」来用，最后栽在几个很具体的地方。
小程序云开发数据库的免费额度，给的是次数不是性能
免费档一般按存储空间、读写次数、出网流量这几项来算，不同套餐版本的数值会调整，具体以官方页面和控制台的用量说明为准。真正要理解的是它的计量逻辑：你打开一次列表，它记的是「读了多少条文档」，不是「发了几次请求」。分页没做好、一次拉几百条、前端在循环里一条一条查，这些在本地开发时毫无感觉，上线后就是实打实的消耗。
还有并发这一项。免费档的并发能力就那么点，做活动、发朋友圈、被公众号带一波流量，第一波高峰过去，接口超时和请求频繁的错误就开始排队。这不是程序写错了，是你买的档位就这样。想验证想法，够用；想撑业务，不够。
读次数才是那张隐形账单
大部分人的直觉是「我数据又不多，能烧多少」。问题在于文档型数据库的查询习惯跟关系库完全不是一回事。写个条件不带索引，它就把整个集合从头翻一遍，翻一遍算一遍读。集合里几千条的时候看不出来，几万条之后，同一个列表页每次刷新都在往外掏额度。
我一般先看两件事：控制台的用量是分维度统计的，先搞清哪个维度在涨；再看那些条件写了三四个字段、却一个索引都没建的查询。索引在云开发里是能加的，只是很多人进控制台只顾着新建集合，索引那一栏压根没点开过。加索引这一步花不了多少时间，收益比后面改代码大得多。
安全规则写歪，等于把库门敞开
小程序端直连数据库，权限全压在安全规则上。默认读写权限如果图省事设成所有用户可读，那用户表和订单表就是公开的——只要有人从包里翻出环境 ID，拿 SDK 就能直接拉走。这种事故我见过不止一次，出问题的往往不是大项目，是赶时间上线的小项目。
规则写完，别只在控制台里点两下就算过。用真机、用非管理员身份去试一遍，该拒的请求是不是真的拒了。涉及写操作的，尽量收进云函数：云函数里操作数据库不受小程序端安全规则的约束，权限判断自己写在代码里，麻烦是麻烦，但边界清楚，出问题也知道该去哪查。
导出和备份，别等出事才想起来
免费档的备份能力通常有限，定时备份、按时间点回档这些功能跟套餐挂钩，能不能用、保留多久，以官方文档为准，别拿别人的截图当依据。真出事的时候——误删集合、脚本跑飞了批量改字段、测试环境连到了正式环境——能不能退回去，全看你之前有没有留好导出的口子。
我的习惯比较土：每周手动导一次 JSON 或 CSV，扔到对象存储或者本地硬盘。数据量小的时候导出很快，等数据涨上去，导出本身也成了麻烦事，所以越早养成越好。另外就是批量脚本先在测试环境跑，云开发可以开多个环境，多开一个环境的成本，比赔一次数据的成本低太多。
什么时候该考虑搬走
判断标准不复杂。一是用量曲线连着几个月贴着额度上限走，每次升配都在犹豫；二是业务上开始出现跨集合统计、复杂关联这类需求。文档库做关联本来就别扭，硬写聚合也能写，但维护成本高，接手的人看着头疼。
迁移的麻烦不在代码改多少行，在数据怎么搬。所以从第一天起就把字段命名、时间格式、状态值统一好，导出的时候少踩点坑。真到要迁的那天，方案里至少要有全量导一次、增量追一段、再切流量这三步，别指望一键搬完，市面上没有那种东西。
上线前挨个过一遍
列表接口有没有写死条数上限；常用查询条件建了几个索引；安全规则是不是从「仅创建者可读写」起步；云函数返回的错误信息有没有把内部细节原样吐给前端；用量告警开了没有。这几条都不难，难的是想起来。写在发布清单里，比记在脑子里靠谱。
免费额度是用来验证想法的，不是用来长期撑业务的。拿它跑通流程、验证需求，很合适；用户量起来之后该升配升配，该搬搬。省下的那点钱，填不上一次数据丢失或者一场活动挂掉的坑。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
