单纯用<picture>标签无法实现渐进式视觉呈现，它只做资源选择，不控制加载过程或过渡效果；必须将其作为底层资源调度器，再叠加DOM结构、CSS过渡或JS逻辑，如用LQIP占位图与高清图分层叠放，配合opacity过渡实现模糊到清晰效果。
单纯用 <picture> 标签无法实现“渐进式视觉呈现”——它只做资源选择，不控制加载过程或过渡效果。 真正让用户看到“模糊→清晰”“占位→填充”的视觉流，必须把 <picture> 当作底层资源调度器，再叠加 DOM 结构、CSS 过渡或 JS 控制逻辑。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
为什么 <picture> 本身不产生渐进效果
浏览器对 <picture> 的处理是“匹配即加载，加载即替换”，没有中间态：
- 它按 <source> 顺序逐条检查 media 或 type，命中第一个就发起请求
- 不预加载未命中的资源，也不缓存 fallback 图的解码状态
- <img> 作为 fallback 是静态回退，不是过渡起点
- 没有内置的 onload 链式回调、opacity 控制或 blur 渐变能力
用 <picture> + 双图叠加结构实现模糊到清晰
这是最稳定、零 JS 依赖的方案，关键在把 LQIP（低质量占位图）和高清图分层叠放，由 CSS 控制显隐：
- 外层 <div> 设固定宽高 + position: relative
- 第一张图（LQIP）放在普通文档流，src 指向缩略图（如 40×30px），用 width: 100%; height: 100% 拉伸，加 filter: blur(6px) 和 opacity: 0.85
- 第二张图用 <picture> 包裹，position: absolute 覆盖其上，初始 opacity: 0，等 onload 后设为 1 并启用 transition: opacity 0.35s
- LQIP 必须带 background（如 #f0f0f0），否则 PNG 透明底会透出页面内容
<div style="position: relative; width: 800px; height: 450px;">
<img src="lqip.jpg" style="width: 100%; height: 100%; filter: blur(6px); opacity: 0.85; background: #f0f0f0;">
<picture style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;">
<source media="(max-width: 768px)" srcset="hero-mobile.jpg">
<source media="(min-width: 769px)" srcset="hero-desktop.jpg">
<img src="hero-fallback.jpg" onload="this.style.opacity='1'" style="width: 100%; height: 100%; opacity: 0; transition: opacity 0.35s;">
</picture>
</div>配合 loading="lazy" 时的 onload 陷阱
直接在 <img> 上写 onload="this.style.opacity='1'" 在 loading="lazy" 下可能失效：
- 浏览器可能在图片尚未渲染进视口前就触发 onload（尤其 SSR 或预加载场景）
- 导致高清图提前淡入，但还在视口外，用户看不到过渡，反而浪费性能
- 更稳妥的做法是用 IntersectionObserver 监听进入视口后再绑定 onload，或改用 CSS @keyframes + animation-play-state 控制淡入时机
- 如果首屏大图必须 eager 加载，就显式设 loading="eager"，避免懒加载干扰视觉节奏
渐进式 JPEG 是唯一原生方案，但限制极多
只有真正保存为“Progressive JPEG”的文件，才能在 <img src="xxx.jpg"> 中触发浏览器原生逐层渲染（先轮廓、后细节）。但要注意：
- <picture> 内所有 <source> 和 <img> 都必须指向 progressive 编码的 JPEG，WebP/PNG 不支持
- 构图不能变化——progressive 只解决单图解码节奏，不解决响应式裁剪
- 压缩率通常比 baseline JPEG 高 5–10%，对小图得不偿失
- 开发者常误以为导出时勾了“渐进”就生效，实际需用 jpegtran -progressive 或 ImageMagick 二次确认编码类型
