图片路径应统一用相对路径“./assets/images/”硬编码，禁用混用或外链；alt需语义化描述“谁+什么+在哪+为什么”；文件名嵌入版本号防缓存；用<picture>实现多格式fallback，<img>作兜底。
图片路径统一用相对路径 + 固定目录结构
硬编码绝对路径或混用 ./、../ 是后期维护最头疼的源头。一旦移动 HTML 文件位置，所有 src 都得重查重改。
实操建议：
- 项目根目录下固定建
./assets/images/（不叫img或photos，避免歧义） - 所有 HTML 中图片引用统一写成
src="./assets/images/logo.png"，不带多余层级 - VSCode 里装「Path Intellisense」插件，输入
./assets/images/后自动补全文件名，减少拼错 - 禁止在
src里写http://或https://外链——除非是 CDN 上的通用图标库（如 Font Awesome 的 SVG sprite）
用 alt 做语义化注释，不只是无障碍需求
alt 不只是给屏幕阅读器看的，更是团队协作时的“图片说明书”。你写的 alt="首页轮播第2张：夏季促销Banner，含折扣码SUMMER20"，比 alt="banner2" 能省下同事三次 Slack 询问。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 留空
alt=""却没确认该图真是纯装饰（比如仅作视觉分隔的div背景图应改用 CSS，而非<img>） - 写成“图片”“此处为图片”这类无效描述
- 把 SEO 关键词堆砌进
alt，比如alt="电商网站 网上购物平台 手机电脑配件"
建议：按「谁+什么+在哪+为什么」四要素精简写，例如：alt="用户头像：张三，个人中心页顶部圆形裁切"。
批量重命名 + 版本号嵌入文件名，绕过浏览器缓存
运营提需求：“把首页 Banner 换成新图”，你替换了 hero.jpg，但用户端还是旧图——不是代码没部署，是浏览器死认这个 URL 没变，直接从缓存取了。
参数式缓存失效（如 ?v=1.2.3）在 HTTP/2 下可能被代理层剥离，更可靠的是改文件名本身：
- 用工具（如 Bulk Rename Utility 或 Python 脚本）把
hero.jpg改成hero-v2-20260930.jpg - HTML 中同步更新为
src="./assets/images/hero-v2-20260930.jpg" - 配合构建脚本自动生成哈希后缀（如 Webpack 的
[contenthash:8]），但小项目手动加日期足够用 - 别用时间戳毫秒级（
?t=1727634386123），它会让每次构建都失效缓存，CDN 和中间代理无法复用
用 <picture> + <source> 管理多格式 fallback，而不是靠 JS 判断
想让现代浏览器用 WebP、Safari 用 JPEG、老 IE 用 PNG，别写一堆 if (isWebPSupported) {...}。浏览器原生支持的 <picture> 更轻量、更可靠。
关键点：
-
<source>的type属性必须精确匹配 MIME 类型，比如type="image/webp"，不能写webp或.webp -
<img>标签必须作为<picture>的最后一个子元素，它是所有<source>都不匹配时的兜底 - 不要为了“兼容 IE”而塞一个无意义的
<source>——IE 不支持<picture>，它会直接忽略整个块，只渲染里面的<img>
示例：
<picture> <source srcset="./assets/images/chart.webp" type="image/webp"> <source srcset="./assets/images/chart.avif" type="image/avif"> <img src="./assets/images/chart.jpg" alt="数据趋势图：2026年Q3增长曲线"> </picture>
真正难的不是写对语法，而是建立团队共识：谁负责更新图片命名规则、谁校验 alt 描述准确性、构建流程是否自动注入哈希——这些细节漏掉一个，资源管理就退回到靠人肉记忆和临时沟通的状态。
