css-loader 的 url 选项需用函数形式精细控制资源处理：url.filter 接收 url 和 resourcepath，返回 true 才交由后续 loader 处理；推荐按路径前缀或正则匹配过滤，避免仅依赖后缀；注意 url: false 会彻底禁用解析，而 filter 返回 false 仍保留其他配置生效；webpack 5+ 应配合 asset/inline 使用，且规则顺序必须为 style-loader → css-loader（带 filter）→ asset/inline。
css-loader 的 url 选项不是开关，而是精细控制入口
很多人以为把 url: false 一设，CSS 里的所有 url() 就都不处理了——这确实能阻止 background-image 被解析，但代价是连字体、SVG sprite、@import 中的 CSS 文件也全被砍掉。真正需要的是「只放过字体和 SVG，拦住 PNG/JPG 背景图」这类策略。这时必须用函数形式的 url.filter，它接收两个参数：url（字符串路径）和 resourcePath（当前 CSS 文件绝对路径），返回 true 才交由后续 loader 处理。
怎么写一个靠谱的 url.filter 函数
常见错误是只看后缀，比如 url.endsWith('.png')，但实际路径可能是 ../assets/bg.jpg?inline 或 ~icons/arrow.svg，直接字符串匹配会漏判或误杀。推荐做法是结合正则 + 路径解析：
- 用
path.dirname(resourcePath)得到 CSS 文件所在目录，再拼接相对路径做真实文件存在性预判（需配合fs.existsSync，仅开发时可用） - 更稳妥的是约定路径前缀，比如所有背景图统一放
./images/bg/，则过滤函数可写为：url: { filter: (url, resourcePath) => !url.startsWith('./images/bg/') } - 若想保留 SVG 图标转 base64（通常体积小、适合内联），但拦截位图，可：
filter: (url) => !/\.(png|jpe?g|gif)$/i.test(url)
注意 url: false 和 url: { filter: () => false } 的区别
前者彻底禁用所有 url() 解析，css-loader 连 require() 调用都不会生成；后者仍会走解析流程，只是每个路径都返回 false，最终等价于没匹配到任何资源——但此时 importLoaders、sourceMap 等配置依然生效，调试体验不同。更重要的是：如果后续规则里有 asset/inline 这类 Webpack 5+ 原生资源模块，url: false 会让它们完全收不到信号，而 filter 返回 false 后，Webpack 仍可能 fallback 到默认资源处理逻辑。
Webpack 5+ 用户请绕开 url-loader，直接用 asset 模块配合 url.filter
现在 url-loader 已归档，asset/inline 是等效替代。但关键点在于：css-loader 的 url.filter 必须在 asset 规则之前生效，否则路径根本传不到资源模块层。典型错误配置是把 asset 规则写在 css-loader 上面，导致 CSS 中的 url('./a.png') 根本不进 css-loader，自然也触发不了 filter。正确顺序是：style-loader → css-loader（带 filter）→ asset/inline，且 asset 规则的 test 必须覆盖对应后缀。
最易被忽略的一点：filter 函数里不能依赖未声明的全局变量或异步逻辑，Webpack 启动时就执行它，报错会导致整个构建失败，且错误堆栈极难定位到具体哪行 filter 代码——建议所有判断都收束在纯函数内，用 console.log 打印 url 和 resourcePath 做验证，比猜强得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
