<picture> 标签只负责按设备能力选择最适配图片，不控制美观；美观由 CSS 实现，如 transform: scale()、border-radius、object-fit 等；其核心是确保加载快、清晰、省带宽，且仅首次渲染时选图，后续交互不触发重选。
picture 标签本身不负责“美观”，只负责选图
<picture> 的核心职责是让浏览器按设备能力（宽度、DPR、MIME 支持）自动加载最合适的图片资源，它不控制布局、不添加动画、不处理 hover 效果。所谓“更美观的图廊”，90% 由 CSS 决定，<picture> 只是确保每张图加载得快、清晰、不浪费带宽。
常见误解是把 <picture> 当成“切换组件”——它不切换，也不重绘；它只在首次渲染时做一次源选择。后续缩放、滚动、hover 都不触发重新选图。
- 想实现悬停放大？靠
transform: scale()+transition，和<picture>无关 - 想让图片圆角/阴影/描边？加在
<img>上，不是<source> - 想网格对齐、等高裁剪？用
display: grid或object-fit: cover，不是靠media断点
picture + img 必须共用同一套 CSS 尺寸逻辑
如果你给 <img> 设置了 width: 100%; height: 200px;，但 sizes 却写成 "100vw"，浏览器会误判渲染宽度，高清屏可能加载 2x 图却只显示 1x 渲染效果，白占带宽。
正确做法是让 sizes 和实际 CSS 占位严格一致：
立即学习“前端免费学习笔记（深入）”；
- 网格中每项固定宽 300px →
sizes="300px" - 全宽容器内图片占 90% 宽度 →
sizes="90vw" - 响应式列数：3 列 →
sizes="(min-width: 768px) 30vw, 90vw"（注意括号和单位）
漏掉 sizes 或写错，srcset 中的 w 描述符就失效，浏览器退回到 <img src>，失去响应式优势。
WebP 优先必须 type + Content-Type 双匹配
很多人写了 <source type="image/webp" srcset="a.webp"...>，但服务器返回的 HTTP 响应头是 Content-Type: image/jpeg，Chrome 会直接标记该请求为 blocked:mime-type 并跳过——哪怕文件名是 .webp。
验证方式很简单：curl -I https://yoursite.com/a.webp，检查返回头是否含 Content-Type: image/webp。Nginx 需显式配置：
location ~* \.webp$ {
add_header Content-Type image/webp;
}没配对的结果：桌面 Chrome 加载 WebP，Safari（不支持 WebP） fallback 到 JPEG，但中间多一次失败请求，首屏延迟增加 200ms+。
CSS Grid 画廊里嵌 的典型结构
别把 <picture> 套在 <div class="item"> 外层——它应该紧贴 <img>，且每个画廊项独立包裹：
<div class="gallery">
<figure class="gallery-item">
<picture>
<source type="image/webp" srcset="p1-400.webp 400w, p1-800.webp 800w" sizes="(min-width: 768px) 30vw, 90vw">
<source type="image/jpeg" srcset="p1-400.jpg 400w, p1-800.jpg 800w" sizes="(min-width: 768px) 30vw, 90vw">
<img src="p1-fallback.jpg" alt="产品图1">
</picture>
</figure>
<!-- 更多 item -->
</div>关键点：
-
<picture>是内联级容器，不影响 Grid 布局流 -
<img>必须保留，它是可访问性锚点，也是降级兜底 - 所有
<source>的sizes值要统一，不能一个写"30vw"、另一个写"100%"
真正容易被忽略的是：当画廊开启懒加载（loading="lazy"）时，<img> 的 src 必须指向真实 fallback 图，不能留空或填占位图 URL——否则 Safari 会完全跳过 <picture> 的源选择逻辑。
