@apply 仅在类名真实复用≥3次、语义明确、无响应式/状态修饰符、无动态变量时使用；否则易致样式失控、调试困难、缺乏ide支持，且不提升可维护性。
@apply 能有效压缩 HTML 中重复出现的类名组合，但它不是万能解药——用错地方反而让样式更难追踪、更难调试。
什么时候该用 @apply？
只在满足以下全部条件时才提取：
- 同一组类名在项目中**真实复用 ≥ 3 次**（不是“可能复用”，是已存在）
- 这组类名代表一个**语义明确的 UI 单元**，比如
btn-primary、card-sm，而不是临时拼凑的布局 hack - 不包含响应式前缀（如
md:px-6）或状态修饰符（如hover:bg-blue-700）——这些必须保留在 HTML 中，否则 JIT 编译器无法按需生成对应 CSS - 不依赖运行时变量（如
@apply bg-[${color}]），@apply只接受静态值
为什么 @apply 容易让样式失控？
常见错误现象：改了 .btn-primary 的 padding，结果所有按钮都变高了，但某个页面的按钮还额外加了 mt-2，你得翻三处才能确认最终高度。
-
@apply是 CSS 层面的复制粘贴，不带作用域隔离 —— 它生成的样式和你在 HTML 里写的类名完全等价，优先级、覆盖逻辑一模一样 - 一旦组件类名被多处
@apply复用，它就不再是“组件”，而成了“全局样式胶水”，改一处，处处响 - VS Code 的 Tailwind IntelliSense 对
@apply内部的类名**不提供补全或跳转支持**，写错了只能靠肉眼排查
@apply 和 JIT 模式的关系
启用 mode: 'jit' 后，@apply 不再影响构建体积 —— JIT 只扫描你实际写的 @apply 规则，不会把整套 padding 工具类都打进去。但 JIT **不解决可维护性问题**。
- 如果你写了
@apply p-4 py-2，JIT 仍会生成.p-4和.py-2两条规则，哪怕你只用这一个组合 - 真正省体积的是
content配置项是否准确 —— 它决定 JIT 扫描哪些文件，而不是你用了多少@apply - 过度提取会让
components.css文件迅速膨胀，变成新的“样式黑洞”，比长 class 列表更难 grep
替代 @apply 的轻量方案
当 @apply 开始让你犹豫“这个到底算不算组件”，试试这些更低侵入的方式：
- 用
data-属性 + CSS 自定义属性驱动变化，比如<button data-variant="outline"></button>配合[data-variant="outline"] { --border-color: #e5e7eb; } - 在 React/Vue 中封装为真组件，把类名逻辑收进
className计算逻辑里，而非塞进 CSS 文件 - 用
eslint-plugin-readable-tailwind自动换行，不改结构，只提升可读性 —— 类名还是那些类名，只是不再挤成一行滚动条
最常被忽略的一点：@apply 解决不了“为什么这个按钮在移动端需要额外 mb-6”的问题。那不是样式冗余，是布局职责没理清。先拆组件，再提样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
