@apply仅在Tailwind主CSS入口文件中生效，需配合@layer components使用，否则样式消失、响应式失效；含修饰符、动态逻辑或复杂关系时应改用组件封装或tailwind-variants。
直接用 @apply 封装重复类名，不是不行，但多数人一写就翻车——样式上线后消失、响应式失效、调试时找不到来源。真正高效的前提是：只在满足硬性条件时才提取，且必须走 @layer components 路径。
为什么@apply单独写会失效
它本质是 PostCSS 插件的语法糖，只在 Tailwind 主 CSS 入口文件（如 src/styles.css）中生效。写在 Vue 的 <style scoped>、React 的 .module.css 或任意非入口 CSS 文件里，会被直接忽略或报错。
- 开发时看着正常，是因为 HMR 或 dev server 缓存了旧样式；构建后 PurgeCSS 清掉未识别的类，线上就白屏
-
@apply不展开响应式前缀（md:px-6）、状态修饰符（hover:bg-blue-700）或变体嵌套（dark:hover:bg-gray-800），这些必须手动补全媒体查询和伪类规则 - 跨行书写会被 PostCSS 截断，比如换行后的
rounded-lg永远不会被编译进去
@layer components 必须这么写
所有自定义组件类必须包裹在 @layer components { } 块内，并放在主 CSS 入口文件中。这是 JIT 编译器识别、PurgeCSS 保留、层优先级控制的唯一可靠方式。
- 入口文件需包含三句基础声明：
@tailwind base、@tailwind components、@tailwind utilities - 每个类只能
@apply原生工具类，不能嵌套其他自定义类（@apply btn-primary报错） - 结构建议分层：基础类（
.btn）定义共性结构，变体类（.btn-primary）叠加主题，尺寸类（.btn-sm）单独定义，避免耦合
哪些情况根本不该用@apply
类名变长，往往不是因为“重复”，而是因为逻辑复杂——多状态、多尺寸、主题切换、运行时条件。这时候抽成静态类，等于把动态问题硬塞进静态壳子里。
立即学习“前端免费学习笔记（深入）”；
- 含
md:、dark:、group-hover:等修饰符的组合，@apply不处理它们的上下文展开 - 需要根据 props 动态开关（如
isDisabled && "opacity-50"），应改用clsx或cn - 组件有插槽、内容投影、子元素样式联动（如
.card-header影响.card内边距），@apply无法表达这种关系 - 你只是“觉得以后会复用”，但当前只出现 1–2 次，强行提取只会增加维护成本
比@apply 更稳的替代方案
当组件开始承担状态、变体、主题职责时，@apply 就不再是解法，而是障眼法。
- React/Vue 中优先封装为真实组件：
<Button variant="outline" size="sm">，把类名逻辑收口到 JSX 层 - 用
tailwind-variants（tv）管理变体组合，支持类型推导、插槽、运行时条件，且不破坏 JIT 编译效率 - 复杂 UI 单元（如卡片、表单组）直接用
data-属性驱动状态，配合 CSS 属性选择器，避免 JS 操作 class - 纯原子级约束（字体基线、禁用灰阶、统一阴影）可用
@apply，但必须限定在@layer utilities或@layer base中，不用于 UI 组件
真正难维护的从来不是类名长度，而是样式决策散落在 HTML、JS、CSS 三个地方。抽组件不是为了“少打几个字”，而是为了把变化点收敛到一处——这点没想清楚，@apply 写得再顺，也只是一地鸡毛。
