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