uniCloud数据库不能仅靠导出JSON实现完整备份恢复，必须手动采集权限规则、索引、Schema定义三类元信息，并通过云函数批量初始化结构与数据。
直接备份和恢复 uniCloud 数据库不能靠「导出 JSON 再导入」一招走天下——那只是数据快照，不包含索引、权限规则、schema 校验、默认值等关键结构信息，上线后极易报 permission denied 或查询超时。
uniCloud 数据库怎么安全导出（含结构）
控制台导出的 JSON 文件只含文档数据，不含任何元信息。真正要跨环境迁移或做灾备，必须分三步手动采集：
- 权限规则：进
uniCloud 控制台 → 数据库 → 集合右侧「设置」→ 权限规则，复制整个 JSON，注意"read"和"write"字段是否为true或带条件表达式 - 索引：进「索引管理」页面，逐个记录字段名、排序方向（
1或-1）、是否unique；MongoDB 兼容层不支持模糊索引，text类型字段需显式建索引才能用于where({ desc: /xxx/ }) - Schema 定义：打开本地项目中的
uniCloud-aliyun/database/users.schema.json（路径依云厂商和集合名而变），确认"schema"节点有字段类型、校验（如"pattern"）、默认值等，且已右键「上传 DB Schema」
漏掉任意一项，恢复后都可能表现为「能连上、能查、但查得慢/写不进/前端报错」。
怎么用云函数批量恢复结构 + 数据
靠人工点控台太容易出错，推荐写一个部署型云函数统一初始化：
- 在
cloudfunctions/init-db/index.js中调用db.collection('users').setRules()设置权限（仅 admin 权限可用） - 用
db.collection('users').createIndex({ status: 1 }, { unique: false })补全索引 - 用
db.collection('users').updateSchema()同步 schema（HBuilderX 3.99+ 支持，旧版需手动改 schema 文件再上传） - 数据导入用
db.collection('users').add()批量插入，别用set()，避免覆盖已有_id
执行前务必确认该云函数的运行权限是 admin，否则 setRules 和 updateSchema 会静默失败。
本地开发时怎么快速重置测试数据
日常调试不需要完整灾备流程，但也不能每次手动删集合——容易误操作清空线上表：
- 新建专用测试集合，如
test_users，和正式集合物理隔离 - 写一个清理云函数：
cloudfunctions/clear-test-data/index.js，用db.collection('test_users').remove({})清空，加where({ _id: /^test_/ })更保险 - 前端调用时传
event.env === 'local'做环境判断，防止误触发生产环境
别在 onLaunch 里自动清库，也别把 remove({}) 写进公共云函数暴露给前端——没鉴权就是删库跑路入口。
真机环境下备份失败的典型表现和修复
App 端用户无感知的“备份失败”，往往不是网络问题，而是本地落盘阶段就断了链：
-
uni.getStorageSync读不到数据？大概率用了uni.setStorage（异步+缓存），被 iOS suspend 或 Android 后台回收清掉了；必须改用uni.setStorageSync存小结构化数据（≤1MB） - 文件路径还在，但
uni.getFileSystemManager().access()报fail no such file？系统已清理沙箱，得先检查文件是否存在，再决定是否重传 - 同步队列
sync_pending_queue越积越多？说明重试时机没选对——onNetworkStatusChange触发时可能还没拿到最新网络状态，建议加setTimeout(..., 500)防抖
最麻烦的不是数据没传上去，而是你以为传上去了，其实卡在本地 pending 队列里，连日志都没打——得在 uniCloud.callFunction 的 .catch 里强制写一条 console.error 并 push 到队列，不然问题永远隐形。
