uni.clearimagecache() 仅在 app 端（app-plus）生效，h5 和小程序中静默失败；需条件编译 #ifdef app-plus 包裹，且无法清理 downloadfile 或 plus.io 写入的图片，小程序须靠 url 版本参数配合服务端缓存策略。
uni.clearImageCache() 为什么调了没反应
它只在 App 端（APP-PLUS）生效，H5 和小程序里调用是静默失败——不报错、不清理、也不提示。常见错误是直接写 uni.clearImageCache() 放在公共逻辑里，结果 H5 用户看到旧图、小程序用户缓存还在，误以为 API 坏了。
必须用条件编译包裹：#ifdef APP-PLUS，否则上线后等于没写。
- Android 部分厂商 ROM（如华为 EMUI、小米 MIUI）会把图片缓存路径重定向，
uni.clearImageCache()只清默认路径，可能漏掉部分缓存，属正常现象，不是 bug - iOS 上该 API 行为稳定，但仅清内存+磁盘缓存中由
uni.getImageInfo或<image></image>标签触发的缓存，不包括手动用uni.downloadFile下载后直接src引用的文件 - 调用后无回调，无法判断是否真清干净；建议清完再 reload 页面或重新
uni.getImageInfo验证
小程序端图片更新延迟怎么破
小程序有自己的图片缓存池，和 WebView 缓存无关，uni.clearImageCache() 完全无效。真正起作用的是资源 URL 的变更策略。
最可靠的方式是在图片 URL 后加版本参数或时间戳，例如：https://cdn.example.com/logo.png?v=1.0.2 或 https://cdn.example.com/avatar.jpg?t=<code>Date.now()。
- 服务端必须配好
Cache-Control: public, max-age=31536000，否则加了参数也容易被 CDN 或中间代理忽略 - 避免用随机数（如
Math.random()），会导致每次请求都绕过缓存，浪费带宽 - 真机调试时务必验证——开发者工具自带强缓存，常掩盖问题；iOS 微信客户端尤其容易卡旧图
App 端图片缓存残留的两种典型场景
一种是 uni.downloadFile 下载后直接赋给 <image src="..."></image>，另一种是通过 plus.io 写入私有目录再读取。这两类都不归 uni.clearImageCache() 管。
- 下载类图片：得先用
uni.getSavedFileList()拿到所有已存文件路径，再逐个调uni.removeSavedFile({filePath: 'xxx'})；注意并发数量，iOS 上超过 5 个并发删容易触发EMFILE: too many open files - 私有目录图片（比如存在
plus.io.getCacheDir()下的缩略图）：必须用plus.io.readdir()+plus.io.remove()手动遍历删除，uni.getFileSystemManager()对该路径无权限 - 别忘了检查 manifest.json 是否勾选“文件系统（plus.io）”，否则
plus.io全部静默失效
为什么加了 v 参数还是加载旧图
不是代码没生效，而是浏览器或 WebView 层把带参数的 URL 当新资源缓存了——下次访问相同 URL 时仍走本地缓存，导致“新参数”形同虚设。
关键点在于：缓存控制权其实在服务端。前端加 v= 只是“骗”客户端发新请求，但若服务端响应头里写了 Cache-Control: max-age=3600，那这个新请求返回的内容依然会被缓存一小时。
- 正确做法是服务端对带
v=或t=的图片响应头设为Cache-Control: no-cache或max-age=0 - 如果用 CDN，需确认 CDN 是否透传 query 参数做缓存键；有些 CDN 默认忽略参数，需在控制台开启“query string 缓存区分”
- H5 端还要额外考虑 Service Worker：如果注册了 SW 并缓存了图片，
v参数对它无效，得在 SW 脚本里主动caches.delete()
