Windi CSS的@apply在Vue SFC中不触发热更新，根本原因是其默认跳过<style>块中的@apply，须显式启用extract模式并配置include路径覆盖.vue文件，否则@apply被静默忽略且HMR无法感知变更。
Windi CSS 的 @apply 在 Vue SFC 中不触发热更新
根本不是语法写错，而是 Windi CSS 默认跳过 <style> 块里的 @apply，除非显式启用 extract 模式。Vite 启动时只扫描 JS/TS 文件中的工具类，<style scoped> 里的 @apply 被直接忽略，后续修改自然不会触发样式重编译。
必须在 windi.config.ts 中配置：
export default defineConfig({
extract: {
include: ['src/**/*.{vue,html,tsx}']
}
})
否则任何 @apply 都不会被识别，更谈不上热更新。
-
include路径没覆盖.vue文件 →@apply完全静默 - 用了
scoped却在同个<style>块里混写@apply和普通类名 → 生成的 CSS 不带data-v-xxx属性，样式漏掉且 HMR 无法定位变更 - 动态 class 字符串（如
:class="`text-${color}-500`"）→ Windi JIT 在首次请求时才扫描，热更新前那段样式根本不存在，浏览器空白几帧
Vite 的 CSS 热替换和 Windi 的 JIT 编译节奏不匹配
Vite 的 HMR 对 CSS 是“文件级替换”，而 Windi 的 JIT 是“按需生成”，二者触发时机不同步。你改了 @apply text-blue-600，Vite 会通知浏览器加载新 CSS，但 Windi 可能还没来得及把 text-blue-600 编译进 CSS 内容里——结果就是样式短暂消失或延迟出现。
立即学习“前端免费学习笔记（深入）”；
这不是 bug，是机制差异。常见表现：
- 保存后控制台没报错，但元素瞬间变回默认样式，100–300ms 后才恢复
- 用
v-if控制的组件首次渲染时，冷门工具类（如backdrop-blur-xl）直接缺失 - 修改
<style>块内@apply，浏览器 Network 面板能看到 CSS 请求返回 200，但响应体里没对应规则
缓解方式：在 setup() 或根组件里提前写一个 dummy class，比如 class="text-sm text-gray-500"，强制 Windi 启动时就生成基础类表。
Windi 插件未正确注册或版本不兼容
Vite 插件链断裂会导致整个 Windi 处理流程被跳过，@apply 不解析、CSS 不注入、HMR 无感知。典型信号是：import.meta.hot 正常，JS 和模板热更新都 OK，唯独样式不动。
检查点：
-
vite.config.ts中是否调用了windicss()？漏掉这行，Windi 就只是个摆设 -
@windijs/vite-plugin和windi.css版本是否匹配？v4.x 插件不兼容 v3.x 的配置格式 - 是否和其他 CSS 工具（如 Tailwind、Bootstrap）共存？Windi 的
scan逻辑可能被干扰，尤其当它们也监听.vue文件时
快速验证：删掉 windi.config.ts，重启 dev server —— 如果此时 @apply 还能生效，说明配置文件压根没被读取。
浏览器缓存或 Vite 服务端模块缓存干扰
Windi 生成的 CSS 是通过 Vite 的虚拟模块（如 /@windi.css）提供的，这个路径容易被浏览器强缓存，尤其是当 HTTP 响应头带 Cache-Control: max-age=31536000 时。你改了 @apply，Vite 服务器其实已生成新内容，但浏览器直接从内存缓存返回旧 CSS。
不用清空全部缓存，只需针对性处理：
- 打开 Chrome DevTools → Network → 勾选 “Disable cache”（仅 DevTools 打开时生效）
- 在
vite.config.ts中临时加一行：server.headers = { 'Cache-Control': 'no-cache' } - 删掉
node_modules/.vite目录 —— 这里缓存了 Windi 解析后的模块 ID 映射，损坏后会导致 HMR 找不到对应模块
真正难排查的是：某些 IDE（如 VS Code）保存文件时先写临时文件再 rename，Vite 的文件监听（chokidar）在 WSL 或 Docker 环境下可能错过事件。此时连 @apply 修改都不会被 Windi 扫描到，更别说热更新了。
