URL版本化是解决PHP修改图片后前台不刷新的根本方案，即通过在图片URL后添加唯一版本参数（如?v=1715823492）使浏览器识别为新资源并重新请求，避免缓存导致的旧图显示问题。
PHP 后台修改图片后前台不刷新，本质是浏览器缓存了旧资源 URL —— 单纯改文件内容没用，必须让 URL 变化或强制失效缓存。
为什么 file_put_contents() 覆盖原图前台不更新
浏览器根据 URL 缓存静态资源。即使 PHP 用 file_put_contents('upload/avatar.jpg', $newData) 覆盖了文件，URL 还是 /upload/avatar.jpg，浏览器可能直接从内存/磁盘缓存加载旧图，根本不会发新请求。
- 服务端返回的 HTTP 响应头若含
Cache-Control: public, max-age=3600，浏览器会缓存 1 小时 -
img标签无版本参数时，URL 不变 → 无法触发重新拉取 - 开发工具 Network 面板里看到状态码是
200 (from memory cache)或304，就是缓存生效了
推荐方案：URL 版本化（最简单可靠）
不依赖轮询，不增加服务器压力，前端感知快，兼容所有浏览器。
- 后台保存图片时，生成唯一标识（如时间戳、
md5(file_content)或数据库自增 ID），拼到 URL 后作为查询参数：/upload/avatar.jpg?v=1715823492 - 前端渲染时，确保
$version每次更新都变化 - 注意：不要用
time()粗粒度时间戳（并发修改可能撞上同一秒），建议用microtime(true)或数据库updated_at字段 - CDN 或 Nginx 默认会缓存带
?v=xxx的 URL，无需额外配置；若需禁用查询参数缓存，Nginx 可加expires off;或设置add_header Cache-Control "no-cache";
长轮询不是首选，但真要实现得避开这些坑
仅适用于需要“实时通知其他用户该头像已更新”这类协同场景，而非解决单次刷新问题。
立即学习“PHP免费学习笔记（深入）”；
- 前端发起一个长期挂起的 AJAX 请求（如
fetch('/api/check-image-change?last_ts=1715823492')），PHP 脚本用sleep(1)循环检查文件filemtime()是否变化，超时（建议 ≤30s）就返回空，前端立即重连 - PHP 脚本必须调用
ignore_user_abort(true)和set_time_limit(0)，否则超时断开后进程被杀，检测中断 - 高并发下每个连接占一个 PHP-FPM 进程，容易耗尽资源；Nginx 默认
proxy_read_timeout是 60s，需同步调大 - 更稳妥的替代是 WebSocket（用 Swoole 或 Workerman），但复杂度陡增，小项目没必要
文件检测别只看 filemtime()
仅靠修改时间判断是否更新有风险：FTP 上传、Git checkout、备份还原等操作可能导致 filemtime 不变但内容已变，或 filemtime 变了但内容其实没动。
- 生产环境建议组合校验：
filemtime($path) > $last_check_time && md5_file($path) !== $last_md5 -
md5_file()对大图（>5MB）较慢，可改用hash_file('xxh128', $path)（需安装 xxHash 扩展，速度快 10 倍） - 如果图片由数据库字段控制（如
user.avatar_hash），直接监听该字段变更比监听文件更准确
URL 版本化是绝大多数场景的终点，长轮询和文件检测属于“知道有这回事，但别轻易用”的范畴。真正难的不是实现轮询，而是让所有前端入口（包括 iframe、第三方 SDK 渲染的头像）都统一走带版本号的 URL —— 这个一致性，比技术选型更关键。
