img { max-width: 100%; height: auto; }仅控制渲染尺寸，不控制资源加载，无法解决清晰度问题；浏览器仍加载src指定的单张图（如2000px图缩至300px显示），导致带宽浪费、LCP延迟、Retina屏模糊。

直接用 img { max-width: 100%; height: auto; } 只能解决“不溢出”问题，但无法保证清晰度——小屏设备加载大图是浪费，大屏显示小图会模糊。真正适配分辨率，必须靠 srcset + sizes 配合浏览器决策，而不是只靠 CSS 缩放。

为什么 max-width: 100% 不能解决清晰度问题

这组 CSS 规则只控制图片“怎么画出来”，不控制“加载哪一张”。浏览器仍会下载 src 指定的那张图（比如 2000px 宽的 JPEG），再强行缩放到 300px 宽显示。结果是：带宽被吃掉、解码压力大、LCP 拖慢、Retina 屏依然糊。

• 内联 width/height 属性会覆盖 height: auto，导致拉伸变形
• 父容器没设宽高（如空 <div> 或 flex 容器未设 <code>min-width），100% 就失去参照
• Flex 容器中 <img alt="HTML图片怎么自适应不同分辨率？清晰度适配指南" > 默认有 min-width: auto，阻止它随容器收缩，需显式加 min-width: 0

srcset + sizes 是怎么选图的

浏览器先根据 sizes 算出“这张图在当前视口下打算占多宽”，再从 srcset 列表里挑最接近且不小于该宽度的资源。不是按 DPR 猜，也不是按屏幕尺寸硬切，而是按**布局宽度**做精准匹配。


DeepBI DHTML 页面生成器
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
下载
• sizes="(max-width: 600px) 100vw, (max-width: 1024px) 50vw, 33vw"：告诉浏览器，“小屏时我让它占满视口，中屏占一半，大屏固定占 1/3 视口”
• srcset="photo-480w.jpg 480w, photo-800w.jpg 800w, photo-1200w.jpg 1200w"：提供物理宽度明确的源图，单位必须是 w（不是 px）
• 漏写 sizes 会导致浏览器 fallback 到 100vw，大概率加载过大的图

如何兼顾艺术方向与格式回退

当不同断点需要不同裁剪（比如手机只显示人脸、桌面显示全身），或想用 WebP/AVIF 但兼容旧浏览器时，<picture></picture> 是唯一可靠方案。它不替代 <img alt="HTML图片怎么自适应不同分辨率？清晰度适配指南" >，而是包裹并接管资源选择逻辑。

立即学习“前端免费学习笔记（深入）”；

• 每个 <source></source> 必须带 media 或 type，且顺序重要：浏览器从上到下匹配第一个满足条件的
• <img alt="HTML图片怎么自适应不同分辨率？清晰度适配指南" > 作为兜底，必须存在，且仍需写 src、alt 和基础 srcset（用于不支持 <picture></picture> 的环境）
• 别把所有尺寸塞进一个 <source></source>；例如手机断点用 media="(max-width: 768px)" + srcset="face-320w.webp 320w"，避免大图干扰小屏决策

容易被忽略的硬性前提

所有响应式图片技术都依赖两个底层事实：图片是替换元素、浏览器按固有宽高比渲染。一旦破坏这个前提，再复杂的 srcset 也救不回布局抖动或模糊。

• 务必写 width 和 height 属性（哪怕只是占位值），否则图片加载前高度为 0，造成 CLS（累计布局偏移）
• loading="lazy" 要配合 decoding="async"，否则解码阻塞主线程，尤其对大图明显
• CDN 或构建工具生成多尺寸图时，确认输出文件名中的 w 值和实际像素宽一致；错标 1200w 却只有 800px 宽，浏览器会误判