<picture> + <source> 实现分辨率适配的核心是让浏览器根据设备像素比（dpr）和视口宽度选择最匹配的图片资源，而非简单裁剪；它通过 media 属性控制触发条件、srcset 提供多分辨率资源、<img> 作为必设兜底项，并配合 object-fit: cover 和宽高约束确保视觉一致。
用 <picture> + <source> 实现分辨率适配
核心不是“裁剪”，而是让浏览器根据设备像素比（dpr）和视口宽度，选择最匹配的图片资源。直接写 <img srcset> 也能做，但 <picture> 更可控，尤其当不同分辨率下需要不同裁剪构图时（比如桌面端要完整场景，移动端只留主体人脸）。
关键点：每个 <source> 的 media 属性控制触发条件，srcset 提供对应资源列表，<img> 是兜底项（必须有，且不能省略 src）。
-
media="(min-width: 768px) and (-webkit-min-device-pixel-ratio: 2), (min-width: 768px) and (min-resolution: 192dpi)"—— 匹配 2x 的平板/桌面屏；注意 Safari 仍依赖-webkit-min-device-pixel-ratio，不能只写min-resolution -
srcset中用逗号分隔多个资源，每项后跟w（原始宽度）或x（像素密度），如"hero-1200w.jpg 1x, hero-2400w.jpg 2x" - 所有图片必须是同一构图比例，否则视觉跳变；若需不同裁剪，得准备多套图（如
hero-desktop.jpg、hero-mobile.jpg），并在不同<source>中指定
用 object-fit: cover 控制容器内裁剪行为
即使选对了图片，如果容器尺寸变化（比如响应式布局中宽高比不固定），图片仍可能被拉伸或留白。object-fit: cover 是唯一可靠方案——它让图片等比缩放并填满容器，溢出部分自动裁剪，类似 CSS 中的 background-size: cover。
必须配合明确的宽高约束使用，否则无效：
立即学习“前端免费学习笔记（深入）”；
- 父容器设
width: 100%; aspect-ratio: 16/9;（现代浏览器），或用 padding-bottom 技巧兼容旧版 -
<img>或<picture>直接子元素设width: 100%; height: 100%; object-fit: cover; - 避免在
<img>上设max-width: 100%同时又设固定height，这会破坏object-fit的计算逻辑
为什么不用 background-image + media query？
看起来更简单，但实际埋雷：背景图无法被屏幕阅读器识别，SEO 友好性归零；无法通过 JavaScript 动态替换或监听加载状态；background-size: cover 在某些安卓 WebView 中存在渲染抖动；更重要的是，你失去了 srcset 和 sizes 对带宽的精细控制——浏览器无法根据 DPR 跳过下载高分辨率背景图。
如果非要用背景图（比如 CMS 不允许改 HTML 结构），至少补上 aria-hidden="true" 并确保内容有语义化替代文本。
容易被忽略的兼容性与性能细节
<picture> 在 IE 完全不支持，哪怕加了 polyfill（如 picturefill），也挡不住其对 srcset 解析的 bug。真要兼容 IE11，只能退回到单图 + <img src> + JS 检测 window.devicePixelRatio 动态换地址。
-
sizes属性常被漏写——它告诉浏览器“这张图在不同断点下大概占多宽”，直接影响srcset中哪个资源被选中；不写就默认按 100vw 计算，可能导致小屏下载大图 - 所有图片必须经过压缩（WebP/AVIF 优先），否则高 DPR 下体积暴涨；工具推荐
squoosh.app或sharpCLI 批量转 AVIF 并保留 alpha - 不要把裁剪逻辑交给前端 JS（比如用 Canvas 裁），既增加首屏阻塞，又无法被预加载器识别
真正难的不是写对标签，而是统一设计稿交付规范：UI 必须提供至少三套裁剪版本（移动/平板/桌面），并标注每套对应的最小宽度和 DPR 覆盖范围。否则代码再准，图不对板，一切白搭。
