图文混排应使用语义化结构：外层用<ul>，每项用<li>包裹<figure><img><figcaption></figure>；CSS用Grid/Flex布局，图片设width:100%;height:auto;display:block;，必填alt和loading="lazy"。
图文混排列表的语义化结构怎么写才不被搜索引擎降权
直接用 <div> 套图和文字是常见错误，搜索引擎会认为内容缺乏结构、可访问性差。正确做法是用 <figure> + <figcaption> 包裹每组图文，外层用语义化的 <article> 或 <section>，列表本身用 <ul>（不是 <div>）——但注意：HTML 标准中 <ul> 不能直接包含 <figure>，必须包一层 <li>。
常见错误现象：Warning: Element figure not allowed as child of element ul in this context（浏览器控制台或验证器报错）。
- 每张图配一段说明，就用
<figure><img><figcaption></figcaption></figure> -
<ul>下只允许子元素为<li>，所以<figure>必须放在<li>内 - 避免给
<figure>加display: inline-block强制换行——用 CSS Grid 或 Flex 控制布局更可靠
CSS 实现响应式图文并列且不塌陷的关键设置
纯靠 float 或 inline-block 容易导致父容器高度坍塌、换行错乱，尤其在小屏下图片撑出容器。现代写法优先用 display: grid 或 display: flex，并配合 min-width: 0 防止图片溢出。
性能影响：不用 JavaScript 就能实现流式排列，CSS Grid 在 Safari 16.4+ 和 Chrome 117+ 支持良好；若需兼容 IE11，改用 Flex 并加 flex-wrap: wrap。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 给
<ul>设display: grid; grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)) - 每项
<li>设margin: 0.5rem，避免间隙靠边粘连 -
<img>必须设width: 100%; height: auto; display: block;，否则底部有空白间隙 - 文字区域用
<p>而非<div>，确保段落语义和默认上下边距
alt 和 loading 属性漏写会导致什么实际问题
没写 alt 不只是 SEO 扣分，屏幕阅读器会跳过整张图，视障用户完全丢失信息；没设 loading="lazy" 则首屏加载大量图片，LCP（最大内容绘制）指标恶化，移动端明显卡顿。
容易踩的坑：alt="" 和没写 alt 效果不同——前者明确告知“此处无文字信息”，后者是无效标记；图标类图片若纯作装饰，alt="" 合理；若含操作含义（如“放大”按钮），必须写清功能。
<img src="xxx.jpg" alt="青椒肉丝特写，红绿椒与酱色肉片搭配" loading="lazy">- 避免
alt="图片"或alt="dish1"这类无意义值 - 如果图是链接，
<a>的title不替代alt，二者作用不同
要不要用 picture 元素？什么场景下值得多写几行代码
只有当你需要为不同设备提供不同尺寸、格式或 DPR 的图片时，<picture> 才有必要。单纯响应式缩放用 <img srcset> 更轻量；想支持 WebP 但兼顾旧浏览器，才上 <picture>。
兼容性注意：Safari 直到 16.4 才支持 <picture> 中的 type="image/avif"，若用 AVIF，得 fallback 到 WebP 再 fallback 到 JPEG。
- 推荐写法：
<picture><source srcset="a.webp" type="image/webp"><img src="a.jpg" alt="..."></picture> - 不要为每张图都套
<picture>，首页首图、商品主图这类关键资源才值得 -
<source>的media属性慎用，多数图文列表更适合用srcset+sizes
真正麻烦的是图床返回的 URL 不带宽高参数，手动填 width/height 容易错位；建议后端 API 返回结构化图片元数据，前端生成 srcset 字符串，而不是硬编码。
