uni.getStorageInfoSync 的 keys 仅表示 setStorage 存储的键名列表，与缓存大小无关；currentSize 才反映 uni.setStorage 数据占用（KB），但不包含 downloadFile、chooseImage 等产生的临时文件及 WebView 缓存。
uni.getStorageInfoSync 返回的 keys 不等于缓存大小
很多人调用 uni.getStorageInfoSync() 后盯着 keys 字段看，以为 key 数量多就代表缓存大——完全误解。这个字段只返回当前 uni.setStorage 存过的 key 名列表，和实际占用的磁盘空间毫无关系。真正反映体积的是 currentSize（单位 KB），但它只统计 uni.setStorage 数据，不包含 uni.setStorageSync 以外的缓存（比如 WebView 资源、图片临时文件、uni.downloadFile 的未清理临时文件）。
实操建议：
-
currentSize是唯一能直接读出的本地存储占用值，但仅限于uni.setStorage系列 API 写入的内容 - 如果 App 用了
uni.downloadFile或uni.chooseImage，它们生成的临时文件不会计入currentSize，必须单独处理 - Android 上
currentSize偶尔会不准（尤其在频繁写入后未触发内部 flush），建议配合uni.getStorageInfo（异步版）多试几次取平均值
uni.downloadFile 下载的文件不自动计入缓存统计
下载后的文件默认存在 uni.env.USER_DATA_PATH 或平台特定临时目录（如 iOS 的 tmp/），uni.getStorageInfoSync 完全看不见它们。用户点了“清空缓存”却发现相册里几十 MB 图片还在，就是这个原因。
实操建议：
- 下载完成后，用
uni.getFileInfo主动查size，自己累加到缓存统计中 - 把下载文件移到
uni.env.USER_DATA_PATH下统一管理，避免散落在tmp被系统自动清理 - 清理时别只调
uni.clearStorage，还得递归扫描uni.env.USER_DATA_PATH下的子目录，用uni.getSavedFileList+uni.removeSavedFile配合uni.getFileSystemManager().readdir手动删
Android 上 getStorageInfoSync 可能返回 0KB
真机调试时偶尔发现 uni.getStorageInfoSync().currentSize === 0，哪怕刚存了 5MB 数据。这不是 bug，是 Android 平台对 Storage API 的实现限制：部分厂商 ROM（尤其 MIUI、EMUI）会延迟同步或限制 JS 层访问底层 SQLite 文件大小统计接口。
实操建议：
- 改用异步版
uni.getStorageInfo，加setTimeout重试（最多 2 次，间隔 300ms） - 不要依赖单次调用结果做 UI 显示，先展示“计算中”，再更新数值
- 若仍为 0，降级显示“未知（仅统计本地存储）”，并提示用户手动清理可释放空间
uni.removeSavedFile 清理失败却不报错
uni.removeSavedFile 的 fail 回调经常不触发，即使文件路径明显不存在。这是因为底层封装了原生 File API，而某些平台（尤其是 iOS 16+）对沙盒路径校验更严格，路径稍有偏差（比如多了斜杠、大小写错误、符号编码问题）就静默失败。
实操建议：
- 删除前先用
uni.getSavedFileList校验目标文件是否在列表中，不在就跳过 - 路径拼接务必用
uni.env.USER_DATA_PATH + '/' + filename，别手写../../或硬编码斜杠方向 - 失败时打印完整路径和
err.errMsg（注意：iOS 可能返回"removeSavedFile:fail file not exist"，Android 可能是空字符串）
缓存大小不是单一 API 能说清的事，它横跨 JS 层存储、原生文件系统、平台沙盒策略三层。最易被忽略的是：WebView 缓存（比如内嵌 H5 的 localStorage、indexDB）完全游离在 uni-app 的 Storage API 之外，这部分只能靠原生插件或重启 WebView 触发清理。
