PostCSS 本身不加版本号，需依赖构建工具（如 Webpack 的 contenthash）或服务端（如 PHP 的 filemtime）；autoprefixer 和 postcss-url 仅处理前缀和路径重写，无哈希生成能力。
PostCSS 本身不处理图片路径或自动加版本号，它只解析和转换 CSS AST；加版本号必须靠构建工具（如 Webpack）或运行时逻辑（如 PHP 的 filemtime）来实现。
为什么 autoprefixer 或 postcss-url 不会给你加 ?v=123
Autoprefixer 只管前缀，postcss-url 默认只做路径重写（比如把 url(./img.png) 转成 url(/dist/img.png)），但不会注入哈希或时间戳。它没有内置版本号生成能力，也不会读取文件内容算 hash。
-
postcss-url的encode选项能把小图转 base64，但不是加版本号 -
postcss-url的assetsPath或basePath是路径映射，不是版本控制 - 真正加版本号的环节在打包阶段（Webpack 的
contenthash）或服务端（PHP 的filemtime）
Webpack 场景下：让 css-loader + mini-css-extract-plugin 自动带 contenthash
这是最常用、也最可靠的方式——版本号来自文件内容哈希，而非时间戳，避免缓存误判。
- 确保你用了
mini-css-extract-plugin（而不是style-loader）提取 CSS 文件 - 在
output.filename和output.chunkFilename中启用[contenthash:8] -
css-loader不需要额外配置，只要它参与了打包流程，引用的图片就会被 Webpack 当作模块处理，最终 CSS 中的url()会自动指向带 hash 的文件名 - 示例输出：
background: url(img/logo.abc123ef.png)，这个abc123ef就是 hash
纯 PostCSS 方案行不通？那 postcss-assets 呢
postcss-assets 插件确实能插入 version 参数，但它依赖手动配置路径和版本策略，实际项目中几乎没人用：
立即学习“前端免费学习笔记（深入）”；
- 它需要你显式写
resolve函数去查文件修改时间，无法对接 Webpack 的 module graph - 它不感知构建产物路径，容易生成错误的相对路径（比如
url(../img/icon.png?v=1712994000)在多级目录下失效） - 它的
v参数是静态值或简单函数返回，不能动态绑定到真实文件 hash - 如果你硬要用，得配成这样：
module.exports = { plugins: [ require('postcss-assets')({ relative: true, cachebuster: (asset) => Date.now() // ❌ 危险！每次构建都变，破坏长期缓存 }) ] }
服务端加版本号更简单：PHP / Node.js 模板里直接插 filemtime
如果你的 CSS 是通过模板（如 PHP、Nunjucks）引入的，这才是轻量又可控的方式——完全绕过构建工具限制。
- WordPress 常用：
wp_enqueue_style('main', get_template_directory_uri() . '/style.css', [], filemtime(get_template_directory() . '/style.css')) - PHP 原生：
<link rel="stylesheet" href="/css/app.css?v=<?php echo filemtime($_SERVER['DOCUMENT_ROOT'] . '/css/app.css'); ?>"> - 注意：
filemtime必须指向真实磁盘路径，不是 URL；且需确保 Web 服务器有读取权限 - 缺点：只对首次加载有效，CDN 缓存可能不识别 query 参数，需额外配置
Cache-Control或使用路径版本（/css/app.123.css）
最容易被忽略的一点：加版本号不是目的，防止旧 CSS 被强缓存才是。用 contenthash 是最健壮的做法；用 filemtime 要小心部署时文件时间未更新；而纯 PostCSS 插件强行加 ?v= 基本等于自废缓存机制。
