wind css的@apply在vue sfc中不生效，根本原因是windi css默认不解析块中的@apply，须启用extract模式并配置include路径，且避免在scoped样式中混用@apply与普通类名。
Wind CSS 的 @apply 在 Vue SFC 中为何不生效
根本原因不是语法写错，而是 Windi CSS 默认不解析 <style></style> 块里的 @apply，除非显式启用「attributify」或「extract」模式。Vue 单文件组件的 <style scoped></style> 会重命名类名，但 @apply 展开的是原始工具类，两者在编译时没对齐。
- 必须在
windi.config.ts中开启extract: { include: ['src/**/*.{vue,html,tsx}'] }，否则@apply完全被忽略 - 避免在
scoped样式中混用@apply和普通类名——@apply生成的样式不会被data-v-xxx属性作用，容易漏样式 - 如果只想要原子类内联效果，直接用
class="text-red-500 bg-blue-100"更稳；@apply适合复用逻辑，但得接受它不参与 scoped 隔离
Bootstrap 5 的 data-bs-toggle 在 Vite + Vue 中点击无响应
不是 JS 没加载，是 Bootstrap 的 DOM 初始化依赖 DOMContentLoaded，而 Vite 的 HMR（热更新）会替换节点却不触发重新初始化，导致 data-bs-toggle 绑定失效。
- 手动调用
bootstrap.Collapse.getOrCreateInstance(el)或new bootstrap.Modal(el)是唯一可靠方式，别依赖 data 属性自动绑定 - Vue 组件
onMounted里初始化，且要加nextTick确保 DOM 渲染完成：nextTick(() => new bootstrap.Modal(el.value)) - 若用
<teleport></teleport>，注意目标容器是否在初始 DOM 中存在——Bootstrap 不监听动态挂载的节点
Wind CSS 的 JIT 模式在开发时样式“延迟出现”
不是卡顿，是 Windi CSS 的按需扫描机制在首次请求 CSS 时才分析源码、生成对应工具类，中间有几十毫秒空白期。尤其搭配 Vue 的 <style></style> 或 JSX 中动态 class 字符串时更明显。
- 提前在
setup()里写死一个 dummy class（如class="text-sm text-gray-500"），能强制 Windi 在启动阶段就生成这些基础类 - 禁用 HMR 的 CSS 热替换（
server.hmr.overlay = false）可缓解闪烁，但代价是样式修改必须刷新页面 - 不要在
v-if深层嵌套中首次使用冷门工具类（比如backdrop-blur-xl），它大概率第一次渲染时缺失
Bootstrap CSS 和 Windi CSS 能否共存
能，但不能共享同一份 class 名空间。比如你同时引入 btn btn-primary（Bootstrap）和 bg-blue-500 hover:bg-blue-600（Windi），它们互不影响；但一旦写了 btn bg-blue-500，两个框架都会试图控制 background-color，最终以 CSS 特性权重和加载顺序为准，结果不可控。
- 全局禁用 Windi 的冲突工具类：在
windi.config.ts的theme.extend.container或blocklist里加入['btn', 'alert', 'form-control'] - Bootstrap 的 CSS 必须放在 Windi 的
@import 'windi.css'之前，否则 Windi 的重置样式（如box-sizing: border-box）可能被覆盖 - 最省心的做法是：路由级隔离——管理后台用 Bootstrap，仪表盘页用 Windi，通过
<style scoped></style>或 CSS-in-JS 切断影响范围
真正麻烦的从来不是“能不能用”，而是哪部分样式该由谁管、谁负责清空副作用、谁来兜底 HMR 失效。选哪个框架不决定体验，怎么切分职责才真正影响开发流速。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
