光靠 max-width: 100% 不足以提升用户体验，它只解决“不溢出”，不解决“加载慢”“糊”“错位”“浪费流量”；真正有效的是组合使用 srcset、sizes、WebP 等现代格式，并配合 loading="lazy" 和语义化结构。
直接说结论：光靠 max-width: 100% 不足以提升用户体验，它只解决“不溢出”，不解决“加载慢”“糊”“错位”“浪费流量”这些真实痛点。真正起作用的是组合使用 srcset、sizes 和现代格式（如 WebP），再配合懒加载和语义化结构。
为什么 max-width: 100% + height: auto 只是起点
这条 CSS 规则确实能防止图片撑破容器，但它对浏览器加载行为毫无影响——手机用户仍可能下载一张 2MB 的 1920px 宽图，然后被缩放到 360px 显示。这既拖慢首屏，又消耗用户流量。
常见错误现象包括：
- 小屏设备上图片加载明显变慢，Network 面板里看到大尺寸原图被请求
- Retina 屏上图片发虚，因为没提供
2x版本 - 图片在 flex/grid 容器中高度塌陷，只因忘了设
height: auto
srcset + sizes 怎么配才不翻车
关键不是堆图片，而是让浏览器能算出“这张图在当前视口下要显示多宽”，再从 srcset 里挑最接近且不小于该宽度的版本。
立即学习“前端免费学习笔记（深入）”；
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
实操建议：
-
sizes必须写真实布局占用宽度，比如侧边栏+主图布局中，主图占 70vw，就别硬写100vw - 用
w描述符（如800w）比x描述符更可靠，尤其在 Chrome 和 Safari 中 -
src属性仍是必要回退，旧浏览器或 JS 禁用时靠它兜底 - 示例中
sizes="(max-width: 600px) 100vw, (max-width: 900px) 50vw, 33vw"对应的是图片容器的响应式宽度，不是屏幕宽度本身
<picture> 什么情况下非用不可
两种典型场景绕不开 <picture>：
-
艺术方向切换：比如桌面端展示全身人像，移动端只保留脸部特写——这时不同
<source>指向裁剪完全不同的图片 -
格式降级：想默认用
webp，但需为不支持的浏览器（如老版 Safari）提供jpg回退，<source type="image/webp">+<img src="fallback.jpg">是唯一标准解法
注意：<picture> 不是 <img> 的增强版，它不支持 loading="lazy" 直接写在自身上，懒加载得加在内部 <img> 标签上。
容易被忽略的细节：语义、格式与测试
很多人花时间调 srcset，却漏掉三个影响体验的关键点：
-
alt文本必须准确描述图像内容，否则屏幕阅读器用户完全不知道你在展示什么 - WebP/AVIF 图片体积通常比 JPEG 小 30%~50%，但生成时要开有损压缩（比如 cwebp -q 75），别盲目转格式却不压质量
- 务必在真机（尤其是低端 Android）上测试：某些浏览器对
sizes解析有偏差，或对 AVIF 支持不稳定
最常被跳过的一步是验证——打开 DevTools 的 Network 面板，强制切到 “Slow 3G”，刷新页面，看实际加载的是哪张图。如果小屏下仍加载了 1200w 版本，说明 sizes 或媒体条件写错了。
