优先选uni.clearstoragesync()登出时“一刀切”,需确认清除结果再跳转则用uni.clearstorage();二者仅清uni.setstorage数据,内存、原生层、插件缓存需手动处理。

uni.clearStorage() 和 uni.clearStorageSync() 怎么选
直接清空所有 uni.setStorage 写入的数据,就用这两个 API。区别很实在:uni.clearStorageSync() 立刻执行、无回调、不抛错(失败也静默),适合登出时“一刀切”;uni.clearStorage() 有 success/fail 回调,适合需要确认清除成功再跳转登录页的流程。
别指望它们能“安全登出”——token、用户信息、设备 ID 可能还在内存(比如 Pinia store)、原生层(Android SharedPreferences / iOS NSUserDefaults)、或插件 SDK 自建的缓存里。只清 storage ≠ 登出完成。
-
uni.clearStorageSync()在 App 端可能触发uni.getSystemInfoSync().deviceId变更(尤其 Android) - 小程序端调用后,微信/支付宝的
openid不受影响,但自己的登录态丢了 - H5 端它只清
localStorage中由uni.setStorage写入的部分,手动用localStorage.setItem()存的完全不管
为什么点了按钮没反应?常见平台陷阱
不是代码写错了,而是平台限制没兜住。最典型的是:uni.clearImageCache() 和 plus.cache.clear() 这类 API 在非 App 环境下静默失效——不报错、不警告、也不起作用。
必须加条件编译,否则上线后白忙活:
#ifdef APP-PLUS uni.clearImageCache(); plus.cache.clear(); #endif
同理,uni.removeSavedFile() 批量删文件时,不能只调一次——它不支持通配符,必须先 uni.getSavedFileList() 拿列表,再逐个传 filePath 调用。iOS 上并发太多会触发 too many open files 错误,建议用 Promise.all() 控制并发数在 5–10 以内。
H5 端容易漏掉的三处缓存
uni.clearStorage() 在 H5 实际只是对 localStorage 的封装,但真实项目里常混用以下三类存储,它们全都不在 uni 清除范围内:
- 手动写的
localStorage.setItem('ab_test_group', 'v2')—— 得自己localStorage.removeItem()或localStorage.clear() -
sessionStorage里的临时数据(比如表单草稿)—— 同样得手动清 - 如果用了 PWA 或自定义 Service Worker,
caches.open('api-cache').then(cache => cache.keys().then(keys => ...))这套是完全独立的,uni 无感
所以 H5 端“彻底清理”,往往要组合三行:
uni.clearStorageSync(); localStorage.clear(); sessionStorage.clear();
按钮点击后怎么验证真清干净了
别只看 console.log 或弹个 toast 就算完。真正要确认,得查两处:
- 查 storage 剩余 key 数和大小:
uni.getStorageInfoSync()返回的keys.length应为 0,currentSize应接近 0 KB - App 端额外验证原生缓存:Android 可读
plus.android.runtimeMainActivity().getCacheDir()下文件;iOS 可调plus.cache.calculate()看总大小是否回落
特别注意:部分 Android 厂商 ROM(如华为 EMUI、小米 MIUI)对图片缓存路径做了定制,uni.clearImageCache() 清不净属于正常现象,不是你代码有问题。











