app端数据备份与恢复需区分类型:小结构化数据用uni.setstoragesync存,文件类数据必须存入uni.env.user_data_path并校验存在性,关键数据须与服务端同步。

App端数据备份与恢复不能只靠 uni.setStorage,必须区分数据类型、存储路径和生命周期——否则杀后台后数据就丢了。
为什么 uni.setStorage 存的数据经常“消失”
因为它是异步 + 临时缓存机制,Android 后台被系统回收、iOS 进入 suspend 状态时,uni.setStorage 的内容大概率被清掉;真机调试时看着还在,一杀进程就没了。
- ✅ 正确做法:小结构化数据(如用户偏好、草稿、最后操作时间)必须用
uni.setStorageSync - ❌ 错误写法:
uni.setStorage({ key: 'user', data: obj })—— 没有同步落盘保障 - ⚠️ 注意:即使用了
setStorageSync,也不能存大对象(>1MB),会卡主线程甚至触发内存警告
文件类数据(图片/音频/离线包)怎么存才不丢
文件不能塞进 storage,得走沙箱文件系统,并手动记录路径。uni-app 的 uni.getFileSystemManager() 是唯一可靠路径,所有文件必须落在 uni.env.USER_DATA_PATH 下。
- ✅ 保存文件示例:
const fs = uni.getFileSystemManager(); fs.saveFile({ tempFilePath: tempPath, filePath: `${uni.env.USER_DATA_PATH}/record_123.m4a`, success: () => { // 记录路径到 storage,供后续读取 uni.setStorageSync('last_record_path', `${uni.env.USER_DATA_PATH}/record_123.m4a`); } }); - ❌ 别用
uni.saveFile:它只是个封装,底层仍可能写到不可靠路径(比如 iOS 的tmp目录,会被系统自动清理) - ⚠️ Android 11+(targetSdkVersion ≥ 30)禁用
WRITE_EXTERNAL_STORAGE,USER_DATA_PATH是唯一合规路径
恢复逻辑要防“空路径”和“文件不存在”
恢复不是简单读 storage 再 JSON.parse,得先校验文件是否真实存在——路径还在,但文件可能已被系统清理或用户手动删了。
- ✅ 恢复前务必检查:
const path = uni.getStorageSync('last_record_path'); if (path && typeof path === 'string') { uni.getFileSystemManager().access({ path, success() { /* 文件存在,可安全读取 */ }, fail() { /* 文件已丢失,需降级处理或提示 */ } }); } - ✅ 小数据恢复建议加版本号字段:
uni.setStorageSync('user_v2', { version: 2, data: obj }),避免旧版代码误读新版结构 - ⚠️ 不要直接
uni.getStorageSync('backup')后无条件JSON.parse——storage 里可能是空字符串、null或已损坏的 JSON,必须try/catch
最易被忽略的一点:App 端没有浏览器那样的持久化保障机制,USER_DATA_PATH 路径下的文件虽稳定,但用户卸载 App 时仍会全清;真正关键的数据(如付费记录、核心配置)必须和服务端对齐,本地只做缓存和离线兜底。











