必须同时设置width和height属性，以防止布局偏移；二者应为图片固有尺寸（像素值），由浏览器提前预留空间，避免CLS飙升和LCP延迟。
img 标签不是“放张图就完事”的摆设，它直接参与页面加载速度、布局稳定性、可访问性评分和 SEO。漏掉一个关键属性，首屏可能跳动、LCP（最大内容绘制）延迟、屏幕阅读器报错——这些都不是事后调试能轻松解决的。
为什么 width 和 height 必须写，且不能只写一个
浏览器解析 HTML 时，如果 img 没有 width 和 height，就无法预留空间。等图片资源下载完成、尺寸确定后，页面会重排（reflow），导致文字上跳、按钮错位——这就是 CLS（累积布局偏移）飙升的主因之一。
- 两个属性必须同时存在，且单位建议用像素（如
width="800" height="600"），不要用百分比或 CSS 单位； - 只设
width不设height，浏览器虽会按比例推算，但 JS 或 CSS 可能覆盖该行为，结果不可控； - 这两个值应严格对应原始图片的**固有尺寸**（intrinsic size），不是你希望它显示成多大——缩放交给 CSS；
- 现代框架（如 Next.js）自动注入尺寸，但纯 HTML 项目里，漏写就是生产事故。
loading="lazy" 的生效条件和致命误用
原生懒加载不是加了就生效。它只对**滚动进入视口前的图片**起作用，且有硬性前提：
- 必须配合
width和height使用，否则懒加载触发时仍会造成布局抖动； - 首屏图片绝不能加
loading="lazy"，否则 LCP 指标直接变红——浏览器会把它当低优先级资源延迟抓取； - 在 Safari 15.4+ 之前，
loading属性完全不支持，需用 IntersectionObserver 手动降级； -
loading="eager"显式声明反而更安全，尤其对 banner、logo 等关键图像。
srcset + sizes 不是“多给几张图”那么简单
很多人把 srcset 当作“高清图备用”，结果所有设备都加载了 2MB 的 4K 图。真正生效靠的是两者的协同：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
srcset列出的是**资源候选集**，格式为"small.jpg 480w, medium.jpg 800w"，其中480w表示该图适用于 480px 宽的容器（不是屏幕宽度）； -
sizes是告诉浏览器：“在不同视口下，这张图的**渲染宽度是多少**”，例如sizes="(max-width: 600px) 100vw, 800px"； - 浏览器根据
sizes计算出目标渲染宽度，再从srcset中挑最接近的资源——如果sizes写错（比如固定写"100vw"却没考虑 sidebar），就永远选不到小图； - 没有
sizes，浏览器默认按 100vw 推算，极易误判。
alt 属性被忽略的真实代价
alt 不是“SEO 加分项”，而是强制可访问性要求。它的缺失会直接触发 axe、Lighthouse 等工具报错，且影响真实用户：
- 空字符串
alt=""合法，仅用于**纯装饰性图片**（如背景分割线、无信息的 icon）； - 写
alt="图片"或alt="photo"等泛化描述，等于没写——屏幕阅读器会朗读，但提供零信息； - 如果是数据图表截图，
alt应概括趋势（如alt="2025年Q1销售额同比增长23%，主要来自华东区"），而不是“柱状图”； - 搜索引擎已不再把
alt当关键词堆砌字段，但缺失时会大幅降低图片搜索曝光率。
性能优化藏在细节里：一张图的 width/height 错了，整页 CLS 就超标；sizes 写得模糊，用户流量全走高带宽路径；alt 描述不具体，等于主动放弃视障用户和图片搜索入口。这些不是“应该做”，而是上线前必须核对的硬性检查点。
