优先选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() 清不净属于正常现象，不是你代码有问题。
