仅靠CSS的width: 100%无法实现响应式图片资源按需加载，因它不改变HTML中src/srcset的资源选择逻辑；必须用srcset和sizes配合HTML结构，Sass @mixin仅用于简化背景图适配的CSS生成。
响应式图片在CSS里为什么不能只靠 width: 100%？
因为width: 100%只控制布局尺寸，不控制实际加载的图片资源。浏览器仍会下载src里写的原图，哪怕它在小屏上只显示100px宽——流量和首屏时间都浪费了。
真正按需加载得靠HTML的srcset和sizes，CSS只能配合做适配层。Sass @mixin在这里的作用是减少重复写断点+尺寸组合的样板代码，不是替代响应式图片语义本身。
- 别把Sass混入当成“自动响应式”，它只是生成CSS，不改变HTML资源选择逻辑
- 必须保留
<img src="low-res.jpg" srcset="..." sizes="...">结构，否则Sass再聪明也救不了 - 移动端优先场景下，
sizes值比srcset更易出错：比如写成sizes="(max-width: 768px) 100vw, 50vw"但没对应提供50vw宽度的图源，浏览器可能退化到加载最大图
Sass @mixin responsive-img 怎么写才不翻车？
核心是让混入接受breakpoints、widths、image-base-name三类参数，生成带min-width媒体查询的background-image规则——仅适用于用背景图实现的响应式场景（如Banner、装饰图）。
注意：这不是给<img>标签用的，别套错地方。
立即学习“前端免费学习笔记（深入）”；
- 路径拼接必须用
#{$base-name}-#{$width}w.jpg，避免硬编码导致雪碧图或CDN路径失效 - 断点单位统一用
px，别混用em或rem，否则和HTML中sizes计算不一致 - 如果项目用
picture元素做艺术指导（art direction），Sass混入完全无能为力，得手写<source media="..." srcset="...">
@mixin responsive-img($base-name, $breakpoints, $widths) {
background-size: cover;
@each $bp, $width in zip($breakpoints, $widths) {
@media (min-width: $bp) {
background-image: url('#{$base-name}-#{$width}w.jpg');
}
}
}什么时候该放弃Sass混入，直接上srcset？
只要图片承担内容语义（比如头像、商品图、图文流里的插图），就必须用<img> + srcset。Sass生成的background-image无法被爬虫索引、不支持懒加载原生属性loading="lazy"、alt文本也无法添加。
-
srcset的宽度描述符（如400w）是告诉浏览器“这张图原始宽度是400px”，不是“在400px宽屏幕上用它”——这点常被误解 - 使用
vw单位写sizes时，要预留滚动条宽度：比如sizes="calc(100vw - 17px)"比"100vw"更准，否则桌面端滚动条出现时布局会跳 - Webpack/Vite项目里，如果用了
url-loader或image-minimizer-webpack-plugin，确保它们处理了srcset里所有变体，否则开发环境正常、生产环境404
常见报错：Failed to load resource: the server responded with a status of 404 () 怎么定位？
90%是因为生成的图片路径和实际文件不匹配，尤其在Sass混入里拼错$base-name或$width变量，或者构建后图片没输出到预期目录。
- 打开浏览器Network面板，过滤
Img类型，看404请求的完整URL，对比srcset属性值或CSS里background-image的url()内容 - 检查构建产物目录结构：Sass混入生成的
url('...')是相对路径，必须和CSS文件位置对齐；如果CSS被打包进/dist/css/，图片就得在/dist/img/下，且路径要同步调整 - Node.js服务（如Express）默认不托管
.jpg等静态资源，需显式配置express.static()中间件，否则本地开发也404
实际项目里最麻烦的从来不是写混入，而是图片资源的命名规范、构建流程中的尺寸生成、以及设计稿给的“视口宽度”和前端sizes计算之间的换算误差。这些环节一断，再漂亮的Sass代码也白搭。
