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 时仍会全清；真正关键的数据（如付费记录、核心配置）必须和服务端对齐，本地只做缓存和离线兜底。
