uni.clearStorageSync() 最直接清空所有 uni.setStorage 数据，同步执行无回调，适合登出或重置；异步版 uni.clearStorage() 有 success/fail 回调；各端清理逻辑差异大，需按平台分别处理缓存与文件。
uni.clearStorageSync() 是最直接的清空方式，但别急着全删
它会立刻清掉所有 uni.setStorage 存进去的数据，包括 token、用户信息、配置项——只要没用系统保留前缀（比如 uni_id_token），就全没了。同步执行，不走回调，适合在登出或重置场景里用。
- 异步版本
uni.clearStorage()有 success/fail 回调，适合需要确认结果再跳转的流程 - App 端清完 Storage，
uni.getSystemInfoSync().deviceId可能变（非 App 平台才稳定） - 小程序端清完，登录态丢了，但微信/支付宝的 openid 不受影响；H5 端则要额外清
localStorage和sessionStorage
清理图片缓存得看平台，uni.clearImageCache() 只在 App 有效
网络图片下载后存在本地，H5 走浏览器缓存机制，小程序有独立图片缓存池，App 则靠 uni.clearImageCache() 主动触发清理。这个 API 在 H5 或小程序里调用是静默失败的，不会报错，但也不起作用。
- App 端必须加条件编译：
#ifdef APP-PLUS包裹，否则上线后可能白忙活 - 它不清理
uni.saveFile或uni.downloadFile保存的文件，那些得走uni.removeSavedFile - 实测部分 Android 厂商 ROM 对图片缓存路径有定制，清不干净属于正常现象，别当成 bug
删文件不能只靠 uni.removeSavedFile()，得先列出来
uni.removeSavedFile() 本身不支持通配符或批量删，必须传 filePath。所以真要清空，得先调 uni.getSavedFileList() 拿列表，再逐个删——而且得注意异步顺序，别一并发请求把系统打崩。
- 推荐用
Promise.all控制并发（最多 5–10 个并发），避免 iOS 上因 too many open files 报错 - 小程序端删文件后，
uni.getImageInfo({src: 'xxx.jpg'})可能仍能读到缓存，需配合timestamp参数强制刷新 - App 端删完记得调
plus.cache.calculate()验证大小，有些残留临时文件藏在getCacheDir()下，uniAPI 触达不到
H5 端缓存最“透明”，但也最容易漏掉 localStorage
UniApp 的 uni.setStorage 在 H5 实际就是封装了 localStorage，但反过来，你手动存进 localStorage 的东西，uni.clearStorage() 是完全不管的。很多开发者以为清了 uni 缓存就万事大吉，结果发现埋点 ID、AB 测试分组还在。
- 上线前务必检查是否混用了
localStorage.setItem——这类数据只能自己清 - 如果用了 PWA 或 Service Worker，
cacheStorage是另一套体系，uni完全无感 - 用户手动清浏览器缓存时，
localStorage通常保留，但sessionStorage一定丢，这点和 App 行为不一致
真正麻烦的不是“怎么清”，而是清完之后哪些状态断了、哪些数据没清到、哪些平台根本不响应——尤其是跨端项目里，一个清除动作背后藏着三套缓存逻辑。
