不能直接用@include加载背景图，因为sass是编译时预处理器，background-image的url必须在编译阶段确定，无法运行时动态加载；所谓“按需加载”实为根据参数生成不同路径、尺寸或格式的css规则，本质是响应式条件输出而非真懒加载。
为什么不能直接用 @include 加载背景图？
因为 Sass 是编译时预处理器，background-image 的 URL 必须在编译阶段就确定，无法像 JS 那样运行时动态加载。所谓“按需加载”，实际是指：**根据传入参数生成不同路径、尺寸或格式的 CSS 规则，让浏览器只下载当前设备真正用到的图片**——本质是响应式 + 条件化输出，不是真·懒加载。
bg-image() 混合宏怎么写才不踩坑？
关键在参数设计和条件判断。常见错误是硬编码路径、忽略 Retina 适配、或把 url() 当字符串拼接导致编译失败。
- 必须用
#{}插值语法包裹路径变量，否则 Sass 会报Invalid CSS - Retina 判断建议用布尔参数（如
$retina: true），而不是靠媒体查询混入——后者会导致重复规则膨胀 - 路径前缀统一用变量（如
$img-base: "../assets/img"），避免各处写死"../images/" - 不要在宏里写
@media，它该由调用方控制上下文
示例：
@mixin bg-image($name, $ext: "png", $retina: false) {
$path: "#{$img-base}/#{$name}.#{$ext}";
background-image: url(#{$path});
@if $retina {
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
background-image: url("#{$img-base}/#{$name}@2x.#{$ext}");
}
}
}
如何支持 WebP + fallback 到 PNG？
纯 Sass 无法检测浏览器是否支持 WebP，但可以用 picture 逻辑模拟：生成两套规则，靠 CSS 层叠优先级让现代浏览器用 WebP，老浏览器退回到 PNG。
- WebP 路径必须显式声明
background-image: url(...)，不能依赖@supports—— 因为@supports (background-image: webp)不合法 - 正确做法是：先写 WebP 规则，再用相同选择器覆盖 PNG，利用 CSS 后声明优先原则
- 注意 WebP 文件名约定（如
icon.webpvsicon.png），避免宏里参数混乱
调用示例：
.logo {
@include bg-image("logo", "webp");
@include bg-image("logo", "png"); // 后写的生效于不支持 WebP 的环境
}
Webpack/Vite 环境下路径别名怎么和 Sass 宏对齐？
如果项目配置了 @/assets 别名，Sass 编译时并不认识它。直接写 url(@/assets/img/bg.jpg) 会编译成字面量，最终 404。
- Webpack 的
sass-resources-loader或 Vite 的css.preprocessorOptions.sass.additionalData可注入全局变量，比如$img-base: "~@/assets/img" - 但
~@/是 Webpack 特有语法，Vite 需改用$img-base: "@/assets/img"并确保vite-plugin-svgr或类似插件已处理别名 - 更稳的方式：Sass 层只管相对路径，构建工具层做路径重写（例如用
postcss-url自动解析）
容易被忽略的是：开发服务器热更新时，Sass 变量修改后可能不触发 CSS 重新生成，需要手动刷新或检查 HMR 配置是否包含 .sass 文件监听。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
