<picture> 标签本身不省内存，真正省内存靠的是 srcset + sizes 配合浏览器按需下载；它只控制加载哪张图，而非解码后内存占用。
picture 标签本身不省内存，它只控制“加载哪张图”，真正省内存靠的是 srcset + sizes 配合浏览器按需下载
为什么直接写 <picture> 不会自动省内存
很多人以为只要把 <img> 换成 <picture> 就能减小内存占用，其实不是。浏览器只要下载了某张图片，就会解码进内存（尤其是大尺寸 JPEG/PNG），和你怎么写 HTML 容器无关。<picture> 的作用是「不让不需要的图被下载」——如果用户设备根本用不上 4K 图，那就别让它进网络请求队列。
常见错误现象：
- 写了一堆 <source>，但没配 sizes 或 media，结果所有图都加载了（尤其在某些旧版 Safari 中）
- 用了 srcset 却漏掉 <img> 的 src 属性，导致降级失败，页面空白
- 必须保证每个
<source>都有明确的匹配条件（media或type），且互斥 -
<img>的src是 fallback，不能空，也不能指向最大图 - WebP/AVIF 等新格式要配
type，否则会被忽略（比如 Chrome 加载了 WebP，但 Safari 回退到 JPEG，你得确保 JPEG 文件也够小）
srcset + sizes 才是关键：让浏览器算出该下哪张
单纯用 media 只能做设备像素比或视口宽度粗筛，真正精准控制加载哪张图，得靠 sizes 告诉浏览器“这张图在当前布局里大概占多宽”，再结合 srcset 里的宽度描述符（如 320w、768w），浏览器才能选最接近又不浪费的资源。
示例：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
<picture> <source media="(max-width: 768px)" srcset="hero-320.webp 320w, hero-768.webp 768w" sizes="100vw"> <source media="(min-width: 769px)" srcset="hero-1200.webp 1200w, hero-2400.webp 2400w" sizes="50vw"> <img src="hero-fallback.jpg" alt="Hero"> </picture>
-
sizes="100vw"表示小屏下图宽占满视口；sizes="50vw"表示大屏下只占一半——这直接影响浏览器选1200w还是2400w - 如果
sizes写成固定值如"600px"，而实际布局是响应式的，浏览器就可能选错 - 不要把所有分辨率都堆进一个
srcset，比如320w, 480w, 768w, 1024w, 1200w, 1440w, 1920w—— 浏览器选图逻辑不是“找最小够用”，而是“找最接近计算出的渲染宽度”，冗余项反而增加解析开销
容易被忽略的内存陷阱：解码后尺寸远大于文件体积
一张 200KB 的 3840×2160 JPEG，解码后内存占用约 3840 × 2160 × 4 字节 ≈ 33MB（RGBA）。哪怕你用 <picture> 让它没被下载，只要某次误配导致它进了页面，内存峰值就上去了。
- 用 Chrome DevTools 的 Memory > Take heap snapshot 查看 ImageBitmap / HTMLImageElement 实例大小，比看 Network 更准
- 服务端生成响应式图时，别只缩放尺寸，还要调低 JPEG 质量（70–80）或启用 AVIF（Chrome/Firefox 支持良好）
- 动态插入
<picture>时，注意不要重复 append 同一 DOM 节点——有些框架（如 Vue 3 的 v-if 切换）会残留解码图像对象
真正省内存的关键不在标签名，而在你有没有让浏览器在下载前就确定“这张图我确实需要”。一旦图进了内存，<picture> 就再没机会插手了。
