必须配sizes，否则浏览器默认按100vw猜测图片显示宽度，高DPR设备会误载大图；sizes需匹配真实布局断点，如"(max-width:768px) 100vw, (max-width:1200px) 50vw, 33vw"，src仍须保留作降级。
为什么只写 srcset 但没配 sizes 还是加载大图
浏览器看到 srcset 里一堆 xxx.jpg 800w，却不知道这张图在页面上实际占多宽——它默认按 100vw 猜，结果高 DPR 设备（比如 iPhone）直接选了 2x 版本，哪怕你只在 320px 宽的卡片里显示。这不是 bug，是规范行为。
必须显式写 sizes，哪怕只是 sizes="100vw"；更推荐按真实布局写，比如：sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"。这样浏览器才能结合视口宽度 + DPR + sizes 预判该加载哪个 w 描述符的资源。
- 不支持
sizes的旧浏览器会退回到src，所以src仍要保留一个合理默认图 -
srcset中每个地址后必须带单位：用w（推荐）或x，不能混写；"a.jpg 1x, b.jpg 2x"和"a.jpg 400w, b.jpg 800w"是两套逻辑，别交叉 - 验证是否生效：Chrome DevTools → Network → 切换设备模拟 → 刷新，看实际加载的是哪个文件名
max-width: 100% 和 width: 100% 的区别到底在哪
只写 width: 100% 会让图片强制填满父容器宽度，同时把高度也“撑”成固定值（或按行内元素默认 baseline 对齐），完全忽略原始宽高比，结果就是拉伸变形。而 max-width: 100%; height: auto 才是安全组合：前者限制上限，后者交还比例控制权给浏览器。
- HTML 属性里的
width和height（如width="1200" height="800"）建议保留，用于防重排（layout shift），值应等于原图尺寸 - CSS 中避免写
width: 300px; height: 200px这类固定像素缩放，那是破坏清晰度的根源 - 移动端 Safari 有时对
max-width: 100%响应迟钝，可加一行width: 100%作为兜底，但必须配合height: auto
WebP/AVIF 怎么 fallback 才不白屏
直接写 <img src="a.webp"> 在 IE、旧 Safari 上就是空白或 404。现代格式必须靠 <picture> 结构兜底，且顺序和 MIME 类型都不能错。
立即学习“前端免费学习笔记（深入）”；
-
<source>必须放在<img>前面，且type属性要精确匹配：例如type="image/webp"，不能写成type="webp" -
<img src="a.jpg" alt="">是 fallback 终点，必须存在，且路径有效 - CDN 或服务器要返回正确的
Content-Type响应头，否则 Chrome 拒绝解析 WebP - AVIF 兼容性略差（Safari 16.4+、Chrome 109+），生产环境建议先用 WebP，再逐步切 AVIF
Canvas 压缩图片时体积反而变大？
常见翻车点不是质量参数设低了，而是没控制输出尺寸或忽略了源图已有压缩特征。比如原图已是 800KB 的 JPG，用 Canvas toDataURL('image/jpeg', 0.9) 导出，结果变成 1.2MB——因为 canvas 没缩放、色度抽样未关闭、甚至用了 PNG 默认格式。
- 务必指定类型：
toDataURL('image/jpeg', 0.75)，0.7–0.8 是视觉无损+体积下降的甜区 - 先缩放 canvas 尺寸（如
ctx.drawImage(img, 0, 0, targetWidth, targetHeight)），再导出，比只调质量更有效 - 原图是透明 PNG？转 JPEG 会丢 alpha，要么加白底合成，要么改用
toDataURL('image/webp') - 大图用
canvas.toBlob()替代toDataURL()，避免 base64 内存膨胀，尤其在 iOS Safari 上
sizes 断点和实际布局宽度对齐、把 HTML width/height 属性值和原图尺寸对齐、把 WebP fallback 的 <source> 顺序和 MIME 类型对齐——三处“对齐”缺一不可，漏一个，高清就变糊，压缩就变慢。 
