图片缓存需服务器配置Cache-Control响应头、合理使用srcset+sizes、CDN与客户端双层缓存、URL稳定哈希化；meta标签无效，immutable关键，禁用查询参数版本控制。
图片加载慢，八成不是网络问题，而是缓存没配对、没分层、没兜底——光靠 src 或 loading="lazy" 压根压不住流量和首屏抖动。
Cache-Control 响应头必须由服务器发，<meta> 标签基本无效
很多人在 <head> 里加 <meta http-equiv="Cache-Control" content="public, max-age=31536000">，以为能长期缓存图片。实际完全不起作用：浏览器只认 HTTP 响应头里的 Cache-Control，<meta> 对图片等外部资源零影响，仅对 HTML 文档本身有极弱约束（且多数现代浏览器已忽略）。
- 静态图片必须通过 Web 服务器配置响应头，例如 Nginx 中：
location ~* \.(jpg|jpeg|png|webp|avif)$ { expires 1y; add_header Cache-Control "public, immutable"; } -
immutable很关键：它告诉浏览器“此资源内容永不变”，避免后续发起If-None-Match验证请求，省掉一次 RTT - 别给图片设
no-cache或max-age=0—— 这等于主动放弃缓存，每次都要 304 验证，比不缓存还慢
srcset + sizes 不只是“多图切换”，它是缓存友好的尺寸锚点
只写 srcset 不配 sizes，浏览器会按视口宽度选图，比如手机访问桌面端布局页，照样拉 1200w 图——不仅浪费带宽，还让同一张图因 URL 不同（img.jpg?w=1200 vs img.jpg?w=480）无法复用缓存。
- 正确写法示例：
<img src="logo-300w.png" srcset="logo-300w.png 300w, logo-600w.png 600w, logo-900w.png 900w" sizes="(max-width: 768px) 100vw, 300px" alt="logo"> -
sizes值必须反映图片在页面中真实渲染宽度，否则srcset的候选图就白列了 - 所有
srcset中的w描述符（如600w）必须与原图真实像素宽一致，否则浏览器计算目标尺寸时会偏差，导致错载+缓存分裂
CDN 缓存 + 客户端缓存要叠用，不能只靠一边
CDN 节点缓存失效，或客户端没设 Cache-Control，都会让“就近加载”变成“就近重复下载”。尤其当 CDN 配置了默认 max-age=300，但你图片实际可缓存一年，这就白白浪费了长期缓存收益。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- CDN 后台需显式设置图片资源的缓存 TTL，优先级高于源站；同时源站仍要返回强缓存头，形成双保险
- 启用 CDN 的自动图像优化（如 Cloudflare Polish、CloudFront Lambda@Edge 转 WebP）时，确保输出的每个变体都有独立、稳定的 URL 和对应缓存头，避免内容协商（
Accept头）导致缓存键混乱 - 禁止用查询参数做版本控制（如
avatar.jpg?v=2），CDN 和代理常忽略参数，导致新旧版共存或缓存击穿；改用文件名哈希（avatar.a1b2c3.jpg）
懒加载不能绕过缓存设计，data-src 也要走完整缓存链路
用 data-src 实现手动懒加载时，如果目标 URL 没走缓存策略，第一次滚动到图时仍会触发全量下载，且无法被后续复用——相当于把“首屏延迟”转嫁成了“滚动卡顿”。
-
data-src的值必须是带完整缓存头的 URL，和正常src无区别；不要指向一个临时生成、无缓存的接口 - 若图片来自 CMS 或用户上传，务必在落盘前重命名并注入哈希，再由 CDN 统一托管，否则
这类路径永远无法被有效缓存 - 配合
IntersectionObserver加载时，记得提前预取（fetch(..., { priority: 'low' })）并设置decoding="async"，防止解码阻塞主线程
最易被忽略的一点：图片资源的缓存有效性，高度依赖 URL 稳定性。任何动态拼接、服务端重定向、或未标准化的大小写/编码，都会让本该复用的缓存变成全新请求——这比没设缓存还糟。
