屏幕阅读器读alt不是简单朗读，而是结合上下文判断是否跳过、合并或强调：alt=""明确忽略，缺失alt时可能读文件名造成信息断层；冗余如alt="图片"、语义不清如alt="公司logo"、undefined渲染为"undefined"均属错误；seo依赖alt真实回答“图里有什么”和“为什么放这张图”，缺失、空格、undefined或堆砌关键词将导致图片被剔除索引；内容图需描述主体+状态+上下文，装饰图必须alt=""，功能图应说明动作意图而非外观；动态渲染中须用alt={item.description || "无描述图片"}等安全写法防失效。
屏幕阅读器怎么读 alt，不是“读出来就行”
屏幕阅读器不只把 alt 当成一段文字朗读，它会结合上下文判断这张图是否该被跳过、合并或强调。比如：alt="" 明确告诉读屏器“忽略此图”，而缺失 alt 属性时，某些读屏器会退而尝试读取文件名（IMG_20240512.jpg）或直接跳过，造成信息断层。
常见错误现象：
- 写
alt="图片"或alt="公司 logo"：读屏器已知这是<img>，重复“图片”属于冗余；“logo”没说明功能，用户不知道点它能返回首页 - 链接内只有图片且无文字，却用
alt="红色耳机"：用户无法得知点击后去哪，应改为alt="查看红色无线耳机详情页" - React 中裸写
alt={item.alt}，当item.alt是undefined，最终渲染为alt="undefined"：读屏器真会念出“undefined”，审计工具 100% 报错
SEO 不给 alt 打分，但没 alt 就等于没图
Google 图片搜索不靠视觉识别，只信任 alt 文本是否真实回答两个问题：“图里有什么”和“为什么放这张图”。它不统计关键词密度，也不给“写得长”加分——但一旦 alt 缺失、是空格、是 undefined 或堆砌关键词（如 alt="前端教程 HTML CSS JavaScript"），这张图就直接从图片索引中剔除。
实际影响：
-
alt值为空字符串alt=""→ 允许爬虫收录页面，但该图不参与图片搜索 -
alt缺失或为undefined→ 爬虫可能降权整页可信度，尤其当页面大量图片都如此 - 内容图写成
alt="产品图"→ 搜索“iPhone 16 Pro 拆机细节”时，你的图根本不会出现 - 文件名仍是第一线索：搜索引擎先看
src路径里的文件名（如iphone-16-pro-teardown.jpg），再比对alt是否一致，不一致会降低匹配可信度
装饰图、功能图、内容图的 alt 写法不能混用
同一张图在不同位置，alt 的职责完全不同。写错不是“不够好”，而是语义污染。
判断依据始终是：这张图是否承载了不可替代的信息？
- 内容图（截图、信息图、产品主图）→ 描述主体+状态+关键上下文，例如
alt="MacBook Pro 14寸侧面接口布局:从左至右为MagSafe、HDMI、两个Thunderbolt 4" - 装饰图（分隔线、背景花纹、纯 icon）→ 必须
alt=""，不能删属性，也不能写alt="装饰性元素"或空格 - 功能图（按钮图标、筛选箭头、提交图标）→ 说明动作意图，不是图形外观，例如
alt="筛选订单状态"，而非alt="下拉箭头" - SVG 替代方案：内联
<svg></svg>不支持alt，必须用<title></title>标签包裹描述，并设aria-hidden="false"
动态渲染和 CMS 场景下 alt 最容易失效
静态 HTML 里手写 alt 很简单，但工程化项目里，它往往在数据流末端被悄悄吃掉。
安全写法示例：
- React：用
alt={item.description || "无描述图片"}，避免undefined渲染；服务端模板更推荐 fallback 到alt="" - Vue：绑定写成
:alt="item.alt || ''"，空字符串比null或undefined更可控 - Yii2：
Html::img()必须显式传入数组参数，如['alt' => '公司首页']，漏掉就等于没写 - CMS 后台：应强制校验「图片描述」字段非空，未填则后端默认输出
alt=""，而不是硬塞alt="image"或文件名
真正难的不是写对一行 alt，是在组件复用、多端适配、CMS 批量导入、CDN 图片回源这些环节里，守住那个空字符串或精准描述的边界。一旦松动，可访问性和 SEO 就不是“差点意思”，而是系统性失效。
