srcset 未生效主因是未配合 sizes 或 sizes 描述与实际渲染宽度不符；单独用仅支持 DPR 切换，需 sizes 告知浏览器图片占位宽度才能按视口选图。
srcset 属性为什么没生效？常见失效原因
浏览器忽略 srcset，通常不是语法写错，而是和 sizes 搭配不当或响应式条件未命中。
-
srcset单独用只能触发设备像素比（dpr）切换，比如2x，但不会根据视口宽度选图 - 必须配合
sizes才能按视口宽度（如(max-width: 768px) 100vw）决定“当前图片占多少空间”，浏览器才据此从srcset列表里挑最匹配的源 - 如果
sizes写成固定值（如sizes="300px"），而实际布局中图片被 CSS 拉伸/压缩，浏览器会按 300px 计算，导致选图偏大或偏小 - 开发时用 Chrome DevTools 的 Network 面板勾选 “Disable cache” + 切换 device mode 后硬刷新，否则可能缓存了上一次选中的图片
怎么写一个真正适配多端的 img 标签
核心是让 sizes 准确反映图片在不同断点下的渲染宽度，srcset 提供对应尺寸的图片资源。
- 先确定 CSS 中图片的响应行为：比如在移动端占满视口，在桌面端固定为 600px 宽，则
sizes应写为sizes="(max-width: 768px) 100vw, 600px" -
srcset列表建议覆盖最小到最大所需尺寸，例如：srcset="photo-400w.jpg 400w, photo-800w.jpg 800w, photo-1200w.jpg 1200w"—— 注意单位必须是w（像素宽度），不是px - 不要混用
x和w描述符，浏览器只认其中一种；w更可控，推荐统一用它 - 记得提供
src作为降级：即使 JS 关闭、旧浏览器不支持srcset，也能加载基础图
<img
src="photo-400w.jpg"
srcset="photo-400w.jpg 400w,
photo-800w.jpg 800w,
photo-1200w.jpg 1200w"
sizes="(max-width: 768px) 100vw, 600px"
alt="描述文字">
Webpack/Vite 构建时怎么自动产出多尺寸图片
手动切图维护成本高，构建阶段生成才是可持续做法，但要注意路径和命名一致性。
- Webpack 用户可用
responsive-loader，配置sizes: [400, 800, 1200]，它会输出 JSON，需配合自定义 loader 或插件拼出srcset字符串 - Vite 推荐用
vite-plugin-imagemin+ 自定义脚本预生成，或直接集成sharp在vite.config.ts的build.rollupOptions.ongenerate钩子中批量处理.jpg/.png - 关键陷阱：生成的文件名必须稳定（如含哈希），否则热更新时路径变化会导致
srcset指向 404；建议关闭图片哈希，或用 contenthash 确保同源图哈希一致 - 别忘了把生成的多尺寸图放进
public/或正确配置assetsInclude，否则打包后找不到
懒加载（loading="lazy"）和 srcset 能一起用吗
能，而且应该一起用，但要注意 Safari 旧版本对两者的组合支持不完整。
立即学习“前端免费学习笔记（深入）”；
- 现代 Chrome/Firefox/Edge 完全支持
loading="lazy"+srcset，浏览器会在滚动进入视口前预判并提前加载最合适的尺寸 - Safari ≤ 15.4 有 bug：若
srcset中某张图 404，整个img可能不触发懒加载，回退到src也不加载；务必保证所有srcset路径真实存在 - 不要用 JS 懒加载库（如 lozad.js）覆盖原生
loading="lazy"，两者冲突可能导致重复请求或尺寸误判 - 服务端渲染（SSR）场景下，首屏图片建议去掉
loading="lazy"，避免因 SSR 无滚动上下文导致图片不显示
srcset 行为强耦合，但很多人只改了 HTML 却没同步更新 CSS 的 width/max-width，结果 sizes 描述和实际渲染宽度对不上——这才是最常被忽略的一环。 
