uni.clearStorage()仅清除localStorage内存缓存,无法清理App沙盒内文件(如USER_DATA_PATH、TEMP_PATH等),真正占空间的是文件系统中的下载文件、离线包及插件缓存。
因为 uni.clearStorage() 只清内存缓存(即 localStorage),不碰 App 实际占用的存储空间——比如 uni.downloadFile() 保存的图片、uni.saveFile() 写入的离线包、uni.getFileSystemManager() 创建的临时/本地文件,这些全在沙盒目录里,uni.clearStorage() 完全无感。
真正占空间的是:uni.env.USER_DATA_PATH(用户数据目录)、uni.env.TEMP_PATH(临时目录)、uni.env.WXFILE_PATH(微信兼容路径,App 端实际映射到本地文件系统)。
USER_DATA_PATH + TEMP_PATH + WebView 缓存 + 插件缓存(如 map、video 组件产生的资源)uni.clearStorage() 仅清 JS 层 key-value,对文件系统零影响不能一上来就 fs.readdir 全删,容易误删正在使用的离线资源或登录凭证文件。得有策略:
uni.getFileSystemManager() 操作,避免混用 plus.io(仅 H5/小程序不支持,且 uni-app 2.x+ 已不推荐)_cache_ 或写入 .meta.json 记录过期时间fs.stat 判断是否为文件(非目录)、是否超过 7 天(Date.now() - stat.birthTimeMs > 7 * 24 * 60 * 60 * 1000)isCleaning = true,清理期间暂停新文件写入逻辑示例片段:
const fs = uni.getFileSystemManager();fs.readdir({ dirPath: uni.env.USER_DATA_PATH, success: res => { res.files.forEach(file => { const fullPath = `${uni.env.USER_DATA_PATH}/${file}`; fs.stat({ filePath: fullPath, success: stat => { if (stat.isFile && Date.now() - stat.birthTimeMs > 7 * 24 * 60 * 60 * 1000) { fs.unlink({ filePath: fullPath }); // 注意:unlink 不返回 promise,需用回调链 } } }); }); }});
这部分完全脱离 JS 控制,但能间接影响:WebView 自身缓存(比如 web-view 加载的 H5 页面资源)由系统管理,uni-app 无 API 清除;地图、音视频等原生插件缓存也独立存在。
plus.webview.getCurrentWebview().setUserAgent() 强制刷新 UA,触发 WebView 缓存失效(副作用:可能重载页面)manifest.json → App SDK 配置 → WebView 设置 中关闭「启用缓存」(影响加载速度,慎开)uni-app-plus 插件,其缓存通常位于 uni.env.USER_DATA_PATH + '/amap_cache',可按名匹配清理uni-video)缓存一般走 TEMP_PATH,建议下载后立刻 moveFile 到 USER_DATA_PATH 并删原临时文件,避免堆积App 启动时执行大体积文件扫描+删除,极易卡顿甚至 ANR(Android)或 watchdog kill(iOS)。必须错峰。
plus.app.onPause),但需判断当前是否真空闲(如无上传/下载任务)onLaunch、onShow 里直接跑 readdir + unlink 循环setTimeout 或 nextTick 分批,防阻塞主线程复杂点在于:你永远不知道哪个文件正被另一个模块读取。所以「安全清理」的本质不是技术多强,而是业务层约定好生命周期——谁创建,谁负责标记和释放。