$assets-url比硬编码路径更可靠，因其将路径逻辑集中到变量层，避免多层嵌套Sass中路径失效、重构风险高及CDN切换困难；推荐用变量拼接而非image-url()等过时函数，并按构建工具适配三档基础路径。
为什么 $assets-url 比硬编码路径更可靠
硬写 url("../images/bg-header.png") 在多层嵌套的 Sass 文件里极易出错：路径随文件位置变化而失效，重构目录时全项目搜替换风险高，而且无法统一切换 CDN 或本地调试前缀。$assets-url 把路径逻辑收口到变量层，所有背景图都基于它拼接，改一处，全局生效。
实操建议：
- 在
_variables.scss里定义：$assets-url: if($env == "prod", "https://cdn.example.com/assets", "/assets"); - 所有背景图统一用
background-image: url(#{$assets-url}/images/#{$name});拼接 - 避免在
@import路径中复用该变量（Sass import 不支持变量插值）
Sass 中 image-url() 函数为何不推荐直接用
image-url() 是 Compass 时代的遗留函数，现代 Sass（Dart Sass）已不内置支持，依赖插件或自定义函数反而增加构建链路脆弱性。它还隐式假设资源在固定相对位置，和 Webpack/Vite 的 asset 处理逻辑冲突，容易导致开发环境能跑、打包后 404。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 使用
image-url("logo.svg")后，Vite 构建提示Undefined mixin image-url - Webpack 中启用
resolve.alias后，image-url()仍按原始相对路径解析，实际文件被移到dist/img/下却找不到
替代方案：用纯变量 + 字符串拼接，可控、无依赖、兼容所有构建工具。
如何让背景图路径适配 Vite / Webpack / 纯 CSS 输出三种场景
关键不在 Sass 本身，而在构建工具对 url() 的处理策略不同。Vite 默认重写 url() 中的相对路径；Webpack 需要 css-loader 配置 esModule: false 才能正确解析变量拼接；纯 CSS 输出（如设计系统交付）则必须用绝对路径避免部署错位。
实操建议：
- 定义三档变量：
$assets-base: "/";（本地开发）、$assets-base: "/dist/";（Webpack）、$assets-base: "/assets/";（CDN） - 背景图一律写成：
background-image: url(#{$assets-base}images/bg-card.jpg); - Vite 用户注意：禁用
css.assetsInclude对 Sass 变量的影响，确保图片后缀在白名单内（如["**/*.png", "**/*.jpg"]）
背景图路径里要不要加哈希？Sass 层怎么配合
Sass 本身无法生成文件哈希，硬塞 bg-header.abc123.png 会导致每次构建都要手动更新变量——这违背自动化初衷。哈希应由构建工具注入，Sass 只负责预留占位结构。
正确做法：
- 保持 Sass 中路径简洁：
background-image: url(#{$assets-url}/images/bg-header.png); - 让 Webpack 的
file-loader或 Vite 的assetsInlineLimit自动重命名并输出映射 - 如果必须 Sass 层控制（极少数定制构建），用
@function封装路径生成逻辑，但需同步维护哈希映射 JSON 文件，复杂度陡增
真正容易被忽略的是：CSS 中的 url() 值一旦被构建工具识别为资源引用，就会走 asset pipeline；如果用了变量拼接但构建工具没配置好 loader，哈希就根本不会出现——此时问题不在 Sass，而在构建配置漏了对 .scss 中动态字符串的解析支持。
