CSS中background-image的url()是字符串字面量，Webpack/Vite默认不解析，需借助postcss-url+sharp等工具链扫描、转码并重写路径，同时注意路径映射、哈希命名与缓存失效问题。
为什么 css-background-image 里的图片不会被 Webpack/Vite 自动转 WebP
因为 CSS 里的 url() 是字符串字面量，打包工具默认不解析其内容——它不关心你写的是 url(./a.jpg) 还是 url(https://example.com/b.png)，更不会去读取文件、检查格式、生成替代图。所谓“CSS 工具自动化识别”，本质是绕过 CSS 解析，直接扫描源码 + 文件系统联动。
- Webpack 的
url-loader或asset-module只处理import/require()引入的资源，对 CSS 中的url()无感知 - Vite 的
assetsInclude配置只影响静态导入，不影响 CSS 字符串中的路径 - PostCSS 插件（如
postcss-url）能重写url()，但本身不生成 WebP，需额外集成图像处理逻辑
用 postcss-url + sharp 扫描并替换未压缩背景图
核心思路：用 PostCSS 解析 CSS，提取所有 url() 路径 → 判断是否为本地图片 → 用 sharp 检查尺寸/质量/格式 → 若非 WebP 且大于阈值（如 10KB），生成 WebP 并改写 URL。
- 必须用绝对路径或项目根相对路径（如
url(../images/bg.jpg)），否则无法定位文件 -
postcss-url的url选项设为'rebase'或'copy'才能触发路径处理 - 生成 WebP 时加
{lossless: false, quality: 80}，避免体积不降反升（尤其对小图） - 示例片段：
postcssUrl({ url: 'rebase', assetsPath: 'dist/assets' })配合自定义transform函数调用sharp
常见错误：WebP 替换后页面白屏或 404
不是代码没跑，而是路径映射断了——CSS 里写的是 url(../images/bg.jpg)，生成的 WebP 存在 dist/assets/images/bg.jpg.webp，但 CSS 被重写成 url(../images/bg.jpg.webp)，而实际服务器没这个路径。
- 确保输出目录结构与源路径一致，或统一用
public/目录托管 WebP，CSS 改为绝对路径url(/images/bg.jpg.webp) - Webpack 用户注意
output.publicPath和css-loader的url选项冲突，可能二次解析导致路径错乱 - Vite 用户要禁用
build.assetsInlineLimit对 WebP 的内联（data:URL），否则url()会被替换成超长 base64，失去缓存优势 - 检查浏览器控制台是否报
net::ERR_ABORTED——大概率是 WebP 文件根本没生成，或权限/大小写问题（BG.JPG≠bg.jpg）
CSS 背景图优化真正难的不是转格式，而是响应式适配和缓存失效
一张 background-image 在 Retina 屏要 @2x，在桌面端要大图、移动端要裁剪，而 WebP 不支持 image-set() 的宽高描述语法（仅支持分辨率描述）。你得手动写多层 @supports (background-image: image-set(...)) + 媒体查询，再配合 JS 动态切换 class。
立即学习“前端免费学习笔记（深入）”；
- 生成 WebP 后，原图修改不会自动触发 WebP 重建 —— 必须监听
.jpg/.png文件变更，或加cache: false强制每次构建都处理 - CDN 缓存可能长期保留旧 CSS，导致新 WebP 路径不生效；建议给 WebP 文件名加哈希（如
bg.a1b2c3.jpg.webp） - 别忘了
picture元素或srcset仍比 CSS 背景图更适合语义化响应式场景——背景图优化是兜底方案，不是首选方案
