app端本地自动备份应使用uni.setstoragesync，仅限≤1mb结构化小数据；大文件须存user_data_path并用setstoragesync记录路径；云端同步需版本校验+失败入队。
自动备份不是“存完就完事”，而是要分层设计：小数据走 uni.setStorageSync 落盘，文件走 uni.env.USER_DATA_PATH 沙箱路径，云端同步必须带版本校验 + 失败入队。不按这个结构做，真机杀进程后大概率丢数据，多端编辑时大概率覆盖。
App端本地自动备份该用哪个 API？
别用 uni.setStorage——它是异步写缓存，后台被系统回收后内容直接消失；uni.setStorageSync 才是唯一可靠的小数据落盘方式。
- 只用于结构化小数据（≤1MB）：用户设置、表单草稿、最后操作时间戳、版本号字段等
- 大文件（图片、录音、离线包）严禁塞进 storage，必须用
uni.getFileSystemManager().saveFile写入uni.env.USER_DATA_PATH - 写完文件后，立刻用
uni.setStorageSync记录路径字符串，比如'last_image_path'，别存二进制或 base64 - Android 11+（
targetSdkVersion ≥ 30）下WRITE_EXTERNAL_STORAGE权限已失效，USER_DATA_PATH是合规且唯一可用路径
云端同步怎么防止多端覆盖和静默丢数据？
直接调 uniCloud.callFunction 推数据上去，没加校验等于裸奔。服务端不会帮你判断“谁改得晚”，它只认你传的 _id 和字段值。
- 本地每次修改必须更新
version字段（数字递增或时间戳），上传前和服务端当前version对比 - 服务端用
db.collection('xxx').where({ _id }).update({ data, version: clientVersion + 1 })，并加条件{ version: $eq: clientVersion }防覆盖 - 失败时返回当前最新
version和完整数据，前端做合并或提示冲突，而不是直接覆盖 - 别用
add()当同步——那是新增记录，不是更新已有数据；要用doc.update()或带_id的set()
什么时候触发同步？不能一改就发请求
频繁联网同步会耗电、卡 UI、触发安卓后台限制，iOS 进入 suspend 后根本发不出请求。得靠状态机控制时机。
- 推荐三个安全窗口：
onUnload（页面卸载）、onHide（App 切后台）、定时器（如每 5 分钟检查一次） - 触发前必须确认：
uni.getNetworkType返回wifi或4g，且uni.onNetworkStatusChange监听到在线状态 - 真机测试时注意：华为/小米/OPPO 等厂商对后台网络有强限制，
onHide后 3–5 秒内可能被系统掐断，建议搭配冷启动时补同步 - 网络失败的数据必须存进本地 pending 队列（用另一个
uni.setStorageSync('sync_queue')），下次启动或网络恢复后再重试
恢复逻辑最容易忽略什么？
恢复不是读出来就直接用。路径还在，文件可能已被系统清理；storage 里有数据，结构可能已升级；服务端有数据，本地版本却更旧。
- 读取文件前必须用
uni.getFileSystemManager().access校验路径真实存在，fail回调里做降级（如清空字段、提示重新上传） - 小数据恢复建议带版本字段，比如存
user_v2而不是user，避免旧版代码解析新版 JSON 出错 - 首次冷启动时，优先拉取云端最新数据（
uniCloud.callFunction+ 版本号），再和本地比对，选高版本合并 - 别假设用户一定在线——离线期间的修改必须能暂存、可回溯、不丢失，这是自动备份的底线
