<picture>无法直接用于动态广告图，因其srcset和media需在HTML解析时确定，而广告数据是运行时返回；应等SDK回调后再用JS动态注入source和img属性。
picture 标签本身不“自适应加载”动态广告图——它只做静态资源选择，无法响应广告系统返回的实时尺寸、设备信息或 A/B 测试变体。 真正起作用的是你如何把它和广告 SDK、渲染时机、服务端逻辑配合。硬套 <picture> 而不控制加载链路，反而容易导致广告图错位、重复请求或 fallback 失败。
为什么直接套用 <picture> 加载广告图大概率失效
广告图不是静态资产，它的 URL、尺寸、格式往往由广告平台在运行时动态注入（比如通过 document.write、iframe 或 JSONP 回调）。而 <picture> 的 <source> 必须在 HTML 解析阶段就确定 media 查询和 srcset 值——此时广告数据还没回来。
- 浏览器解析到
<picture>时，所有srcset和media都已固化，无法根据广告返回的width/height动态生成断点 - 广告平台返回的图片 URL 常带签名、时间戳或设备标识参数（如
/ad?id=123&dpr=2&w=320），这些无法提前写死进srcset - 多数广告 SDK 会自己处理懒加载、格式降级（如 WebP → JPEG）、DPR 适配，再叠一层
<picture>可能引发冲突，比如两次loading="lazy"导致首屏广告不触发
真正可用的组合方案：picture + 动态属性注入
不是放弃 <picture>，而是把它当“壳”，等广告数据就绪后再填充内容。关键动作是：等广告 SDK 触发回调（如 onAdLoaded），再用 JS 设置 <source> 的 srcset 和 <img> 的 src。
- HTML 中先留空结构，但必须含
<img>和alt（否则无兜底）：<picture id="ad-picture"> <source media="(max-width: 479px)"> <source media="(min-width: 480px) and (max-width: 1023px)"> <source media="(min-width: 1024px)"> <img src="" alt="广告内容"> </picture>
- JS 中拿到广告元数据后，按设备宽度匹配断点，拼出对应 URL：
adData.urls.mobile、adData.urls.desktop，然后分别赋给对应<source>的srcset - 务必手动触发一次
img.src = img.src或img.setAttribute('src', ...)，强制浏览器重新评估<picture>选择逻辑（否则可能卡在空src）
比 picture 更适合广告图的轻量替代方案
对大多数动态广告位，<img> 配合 srcset + sizes 更实际，因为广告系统通常只变宽高比，不换构图。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用
sizes描述广告容器在各断点下的实际宽度（如sizes="(max-width: 479px) 100vw, (min-width: 480px) 320px"），让浏览器预估所需像素宽度 -
srcset写成服务端可替换模板："/ad?w=320" 320w, "/ad?w=640" 640w, "/ad?w=1280" 1280w—— 实际请求时由 CDN 或广告网关按参数动态生成对应尺寸图 - 避免用
x描述符（如2x），因为广告平台一般不返回window.devicePixelRatio，且 DPR 与广告点击率无关，纯属冗余开销
最易被忽略的一点：广告图的 alt 必须动态设置。很多 SDK 返回的广告元数据里包含文案字段（如 adData.alt_text），如果始终用固定 alt="广告"，既违反可访问性要求，也会在部分广告平台触发审核失败。
立即学习“前端免费学习笔记（深入）”；
