Vite 仍加载 PostCSS 插件

已经写了一个空的 postcss.empty.cjs，再把它的路径填进 Vite 的 css.postcss，构建却仍受到其他 PostCSS 插件影响。先检查这个配置项的含义：字符串用于指定搜索配置的起点，不是直接选中某个配置文件。

想关闭这次构建的外部 PostCSS 配置搜索，应使用内联配置对象。路径看起来指向一个空文件，并不能证明根目录的 postcss.config.mjs 没有被加载。

一个字符串路径为什么会找到另一份配置

例如现有配置片段是：

css: {
  postcss: '/absolute/project/postcss.empty.cjs'
}

这里的路径只是示意，需要按项目实际目录核对。Vite 把字符串交给 PostCSS 配置加载器作为 searchPath，并按配置搜索规则查找；它不会把该字符串当成“只执行这个文件”的承诺。

因此，旁边或上层的正式 PostCSS 配置仍可能参与构建。项目同时使用 @tailwindcss/vite 和根目录 PostCSS 插件时，很容易把这件事误认为只剩 Vite 插件路径，实际上两条处理路径并没有被隔离。

已核对的 Vite 8.3.4 仍保留这一字符串搜索语义。它是配置方式的区别，不能以“再升级一次”代替修正配置。

需要空配置，就传空对象

确认这次构建确实不需要外部 PostCSS 插件后，在原有 Vite 配置里把对应部分改为内联对象：

css: {
  postcss: {}
}

保留原来的其他 CSS、插件和构建选项。内联对象使 Vite 使用这份配置，不再搜索外部 PostCSS 配置；空对象的插件列表也为空。

这并不会禁用 @tailwindcss/vite、Sass 或其他独立的 Vite 插件。若项目本来就需要某个 PostCSS 处理步骤，不能直接照抄空对象，而应把需要的插件按项目约定写进内联配置，或者继续使用已明确核对的外部搜索目录。

多份 Vite 配置并存时，还要检查实际构建选择的配置文件和最终合并结果。改了开发配置，构建脚本却指向另一份文件，输出不会因此改变。

CSS 的 url 错误要重新定位

一个容易混淆的表现是：资源已经生成带哈希的文件，CSS 中的 url() 却仍指向源码相对路径。Vite 8.2.2 与 Tailwind、postcss-lightningcss 混合使用的环境曾出现过这种观察，但不能把它直接归为“纯 Tailwind 路径也有同一回归”。

如果所谓空配置实际上搜索到了根目录插件，比较的就不是两个互相独立的处理链。先用正确内联配置隔离所需路径，再看错误是否仍出现。若去掉外部 PostCSS 处理后问题消失，下一步应核对该插件如何改写或替换 CSS 节点，以及它与 Vite URL 重写的执行顺序。

若仍复现，则保留实际加载的插件、精确版本和生成 CSS，继续分析。空对象只解决配置搜索的误解，不承诺修复所有资源 URL，也不能证明必须回退 Vite。

检查最终配置与产物

通过项目已有的受控构建流程，核对实际生效的 css.postcss 是对象，并确认需要的 Vite 插件仍在。随后检查原先失败的 CSS 和资源 URL，确保浏览器能够请求到正确文件。

不要只凭空配置文件存在、构建命令退出成功或某个目录里出现资源文件，就认定处理链正确。这里需要确认的是哪份配置真正被加载，以及生成 CSS 最终引用了什么地址。