上周一个做餐饮小程序的老哥找我，说后台会员数据全乱了，积分对不上，订单金额少了两位。我问他多久没看过数据库了，他说上线之后就没管过，反正“云开发自动的”。
这话我听了不下十次。小程序数据维护这件事，最容易被独立开发者忽略，因为它在“做完上线”之后，不在交付清单里，客户不提，自己也不想碰。但真出问题，修起来比当初写代码还费劲。
这篇就聊聊我踩过的坑，以及现在怎么做的。
先搞清楚：数据维护到底在维护什么
很多人以为数据维护就是“备份”。备份当然要做，但只做备份，等于家里着火了才想起来买灭火器。
我一般把小程序的数据维护拆成四块：
- 结构层：集合、字段、索引有没有随业务变化调整。比如订单表早期没加状态字段，后来硬塞进备注里，查询全靠字符串匹配，慢得离谱。
- 一致性层：用户表和积分表、订单表和库存表之间有没有对不上的。小程序端并发不高，但两个用户同时下单抢最后一个库存的情况，我见过。
- 容量层：云数据库免费额度、存储空间、云函数调用次数，这些是有上限的。有个客户做活动，一天把当月云函数额度跑光了，第二天整个小程序白屏。
- 可回溯层：出问题能不能查到“谁在什么时候改了什么”。没有操作日志，排查全靠猜。
云开发场景下的几个实操习惯
1. 给关键集合加“软删除”和更新时间
别直接 remove。我现在的习惯是每个业务集合都带 isDeleted 和 updateTime，删除只改标记。用户误删、运营手滑、脚本跑错，都能捞回来。
// 软删除示例
await db.collection('orders').doc(id).update({
data: {
isDeleted: true,
updateTime: db.serverDate(),
deletedBy: openid
}
})
2. 定时任务做数据体检，而不是等报警
云开发的定时触发器很好用。我一般挂一个每天凌晨跑的云函数，做三件事：统计各集合条数、检查关键字段为空的数据、比对订单总额和明细总额。结果写进一张 health_log 表，手机上用云开发控制台就能看。
不用做得太复杂，几十行代码，跑一周就能发现很多“平时没人注意”的脏数据。
3. 备份要能恢复，不能只导出
云开发控制台可以导出集合数据，但很多人导完就放那了。我建议至少做一次恢复演练：把导出的 JSON 导进测试环境，看看字段类型、时间格式、关联 ID 对不对得上。我遇到过一次导出再导入后，日期全变成字符串，前端排序直接乱掉。
4. 给写操作留痕
凡是运营后台能改的数据，都加一条操作日志。不用上什么日志系统，就一个 op_log 集合，记录 openid、action、collection、docId、before、after、time。出问题时翻日志，比问“你改了什么”高效一百倍。
几个容易翻车的细节
- 索引别乱建：云开发建索引方便，但每个索引都占空间、影响写入。只给高频查询字段建，建完看慢查询日志再调整。
- 云函数超时和重试：涉及写多张表的逻辑，要么用事务，要么做幂等。重试机制会放大脏数据，这点吃过亏。
- 别在客户端直接改敏感数据：权限规则要收窄，能走云函数的写操作就别开放给小程序端。
- 版本发布前跑一次数据快照：尤其是改表结构的时候，留个快照，回滚有底。
最后说句实在话
数据维护不是技术炫技，是给自己留后路。独立开发者一个人扛项目，最怕的不是需求多，是半夜被电话叫醒说“数据没了”。
我现在接新项目，上线前一定把这几件事写进交付清单：软删除、定时体检、备份恢复演练、操作日志。花不了两天，但能省掉后面无数个糟心的夜晚。
如果你手上有个跑了一段时间的小程序，建议这周就打开云开发控制台，看看数据量、看看有没有空字段、看看备份是不是还在。很多问题，看一眼就能提前发现。
评论 (0)
还没有评论，快来抢沙发吧~