微信内置浏览器图片不刷新本质是缓存策略过强，需通过URL时间戳、服务端响应头（no-store）、CDN/NGINX UA识别配置、动态PHP输出或base64等方式综合解决。
微信内置浏览器图片不刷新，本质是缓存策略太激进
微信 iOS/Android 内置 WebView 对静态资源（尤其是 .jpg、.png）默认启用强缓存 + 协商缓存组合策略，且 UA 识别为 MicroMessenger 时，部分 CDN 或 Nginx 会主动延长缓存时间。用户换图后 URL 不变，微信就直接从本地磁盘读旧资源，根本不会发请求 —— 这不是 PHP 后端的问题，而是前端资源交付链路被“卡住”了。
PHP 后端加时间戳参数必须带在 URL 上，不能只改 src 变量值
常见错误：PHP 拼接了 $img_url . '?t=' . time()，但前端 JS 又用 Vue/React 二次赋值或复用 DOM 节点，导致实际渲染的 src 仍是旧值；或者用了 background-image CSS 属性却没同步更新内联样式。
- 确保 PHP 输出的 HTML 中，
t参数是实时生成、每次页面加载都不同 - 避免在 JS 中缓存图片 URL 字符串，比如
const imgSrc = document.getElementById('avatar').src—— 这个值可能已是带旧时间戳的 - 如果走 AJAX 加载头像，接口返回的图片路径字段（如
avatar_url）也必须由 PHP 实时拼好时间戳，不要前端自己拼
微信 UA 下禁用强缓存需服务端配合设置响应头
单靠时间戳治标不治本。微信 WebView 在某些版本里会忽略 Cache-Control: no-cache，但对 Cache-Control: no-store 更敏感；同时要防止反向代理（如 Nginx、CDN）覆盖 PHP 设置的头。
- PHP 中输出图片前（或通过中间件），明确设：
header('Cache-Control: no-store, must-revalidate'); header('Pragma: no-cache'); header('Expires: 0'); - 检查 Web 服务器配置：Nginx 若有
expires 1h;这类指令，会对所有图片生效，需加条件判断 UA —— 例如用map $http_user_agent $cache_control区分MicroMessenger - CDN（如腾讯云 CDN、Cloudflare）默认缓存图片，必须在缓存规则中添加 UA 匹配条件，对含
MicroMessenger的请求关闭缓存或设置极短 TTL
更可靠的做法：用 PHP 输出 base64 图片或动态路由绕过缓存
当时间戳和响应头仍不稳定（尤其 iOS 微信 8.0.44+ 对 PNG 缓存异常顽固），可放弃静态文件路径，让 PHP 直接承担图片输出职责。
立即学习“PHP免费学习笔记（深入）”；
- 把图片存在服务器（非 Web 可访问目录），用 PHP 脚本读取并输出：
readfile('/path/to/avatar_123.jpg'); header('Content-Type: image/jpeg');，URL 形如/api/image.php?id=123&t=1715823409 - 或直接输出 base64：
echo '@@##@@';
—— 完全规避 HTTP 缓存，但注意大图会导致 HTML 体积暴涨 - 关键点：这类动态路径必须确保每次请求的 query 参数（如
t或rand）不可预测，不能用简单递增 ID，否则微信可能预加载并缓存
真正难处理的是混合场景：用户刚上传新头像，老页面还没刷新，而新页面又依赖微信 JS-SDK 的 chooseImage 回调路径。这时候光靠 PHP 输出头没用，得前后端约定强制刷新机制，比如上传成功后触发 location.reload(true) 或清空特定 DOM 节点再重绘 —— 微信里 reload 的行为本身也有 UA 差异，得实测。)%20.%20')
