仅用max-width:100%无法实现响应式图片，因它只控制显示缩放，不干预资源选择；真适配必须依赖srcset+sizes驱动浏览器精准加载合适尺寸图片，<picture>仅在需艺术裁剪或格式降级时使用。
只用 max-width: 100% 做个人博客图片，等于没做响应式——手机照常下载 2000px 宽的图，带宽白耗、加载变慢、用户跳出率上升。真适配必须靠 srcset + sizes 驱动浏览器选图，<picture> 仅在需要裁剪构图或强制格式降级时才上。
为什么 max-width: 100% 单独写就是错的
它只管“怎么画”，不管“下哪张”。一张 1920×1080 的 JPG 在 iPhone 上仍会完整下载，再缩到 375px 宽显示，实际有效像素不到 5%，其余全是流量浪费。
-
height: auto必须和max-width: 100%成对出现，否则图片拉伸变形 - 父容器是
display: flex（比如博客侧边栏+主内容布局）时，<img>默认有min-width: auto，会卡住不收缩，得显式加min-width: 0 - 它完全不触发浏览器的资源选择逻辑——只有
srcset和<picture>才能告诉浏览器“别下大图”
srcset + sizes 怎么写才不被浏览器忽略
漏写 sizes、混用 w 和 x 描述符、sizes 值和真实布局脱节，三者任一发生，浏览器就直接跳过整个 srcset，退化为只加载 src。
-
srcset里只能统一用w（如"small.jpg 480w, medium.jpg 768w"）或统一用x（如"low.jpg 1x, high.jpg 2x"），不能混写 -
sizes是字符串，不是 CSS：不支持calc()，但支持媒体查询语法，例如sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" - 如果博客正文最大宽 1200px，图片占满宽度，那么
sizes就该是"(max-width: 768px) 100vw, 1200px"；若图片在栅格中占 1/3，且断点从 768px 开始，则应为"(max-width: 768px) 100vw, 33.33vw" - 旧版 Edge（EdgeHTML）解析
sizes时，媒体查询里有空格（如(max-width: 768px)）会导致整个属性失效
<picture> 什么情况下非用不可
仅适配分辨率差异时，srcset + sizes 更轻量；<picture> 是为解决两类硬需求：美术方向裁剪（比如手机只留人脸、桌面展全景）、格式强制降级（优先 WebP，fallback JPEG）。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
<source>的media和type是 AND 关系：浏览器跳过任何不满足其一的项 - 顺序决定优先级：最具体的规则放最前，兜底的
<img>必须放在最后 -
type="image/webp"若拼错（如多写分号或大小写错误），浏览器直接跳过该<source>，不会报错也不会提示 - 所有
<source>的srcset若含2x，必须对应标注设备像素比，否则 Retina 屏仍加载低清图
博客图片墙用 Grid 还是 Flex？怎么防塌陷
Flex + flex-wrap 在图片尺寸不一致或动态加载时极易断行错位、最后一行留白；Grid 的 auto-fit + minmax() 才是稳定解。
- 核心写法：
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr))—— 每列最小 250px（保证可读性），容器够宽就自动加列 - 必须用
gap控制间距，别用margin模拟，否则网格对齐逻辑会崩 - 原始图宽高比不一致？统一加
aspect-ratio: 4/3（现代浏览器全支持），再配object-fit: cover裁剪居中 - 每个图单元必须用
<figure>包裹，否则 Safari 和旧版 Chrome 对裸<img>的网格计算容易出错
真正麻烦的从来不是语法写不对，而是 CSS 布局变了但 sizes 没同步更新，或者 srcset 提供的宽度候选值和实际渲染宽度差了一截——这些细节不验证，上线后流量照烧，用户照等，你却查不出问题在哪。
