简介：Tailwind CSS 6.23 组件库资源包，专为使用 Tailwind CSS 的前端开发者准备，覆盖按钮、表单、导航栏、卡片、模态框等常见 UI 组件，既可直接套用也可作为定制基础。资源共 2007 个文件，其中 1304 个 HTML 用于展示各组件效果，605 个 Vue 文件提供组件化封装，便于在 Vue 项目中复用，另有少量 CSS、JS、JSON 配置与 PNG 图片辅助说明，压缩包整体 50.94MB。包内展示了 utility-first 工具类、响应式断点、暗黑模式等核心机制，并体现 JIT 编译与可定制主题的实际用法，帮助理解按需生成样式的优化思路。组件示例按模块划分，入口文件和依赖配置齐全，适合需要快速搭建页面原型或系统学习 Tailwind 组件写法的初中级前端工程师。已有 301 人浏览学习，可作为组件选型与实现参考。
1. tailwindcss-components-6.23：不是组件库，是一套可以拆着用的 Tailwind 组件方案
tailwindcss-components-6.23 是一套基于 Tailwind 工具类封装好的组件片段集合，6.23 是它的版本标识。它跟传统组件库最大的区别是：不提供新的标签语法，不绑定任何前端框架，也不强加运行时依赖，给你的是一批写好的类名组合和 HTML 结构模板，复制进工程就能用，想改哪里直接改类名。常见做法是把这套组件当成团队内部 UI 规范的起点，后台管理、内容系统、活动页这类场景尤其合适。如果你已经受够了重型组件库带来的定制困难和体积开销，这个方向值得投入。下文从接入、组件写法、主题定制、踩坑、固化五个层面展开，覆盖从认识到能用的完整路径。
2. 把 6.23 接进现有工程：版本匹配与最小接入
在动手拷贝文件之前，我建议先花五分钟确认三件事：项目里 Tailwind 的主版本、当前构建链路、以及全局样式文件的现状。这三件事决定了接进去是顺滑还是折腾。很多团队拿到组件集合后第一反应是直接复制粘贴，结果样式出不来，回头排查半天才发现是版本问题。
2.1 先查三件事：Tailwind 主版本、Node 环境、构建链路
Tailwind 3.x 和 4.x 之间，配置文件体系和指令写法几乎是两套东西。3.x 用 tailwind.config.js 配合 @tailwind 指令，通过 PostCSS 插件做构建；4.x 把配置重心移到了 CSS 里的 @theme，默认构建器内置在包内。6.23 这套组件的类名绝大部分是纯工具类组合，不像那些深度依赖配置插件的重型方案，所以主版本不影响类名本身，但影响你抄配置的方式。
第一件事是确认 Tailwind 主版本。打开项目根目录执行下面命令：
node -v cat package.json | grep -E "tailwindcss|postcss"输出一般长这样：
node: v20.11.0 tailwindcss: ^3.4.0逻辑说明：node -v 是为了确认 Node 版本。Tailwind 3.x 在 Node 16 以下会有兼容告警，4.x 对 Node 版本要求更高，通常需要 Node 20 及以上才能正常跑构建。如果你还在 Node 14 的老工程里，6.23 这类依赖现代 Tailwind 的组件集合会很吃力，第一件事应该是先升级 Node 再说。grep 里的 postcss 是顺带确认你用的是不是 PostCSS 链路，这决定了后面组件样式怎么被编译。
第二件事是构建链路。常见的是 Vite 或者 Webpack。这一步影响的是组件片段里那些带交互的部分怎么接进你的框架。组件集合给出的是原生 HTML 和类名，在 React 里要把 class 改成 className，在 Vue 里 class 可以原样保留但事件要换成 @click。这个转换不复杂，但提前想清楚能少踩很多坑。
第三件事是全局样式文件的现状。找到入口 CSS，看里面有没有已经写好的 @tailwind 指令，以及是否引用了别的 UI 库样式。如果项目里已经存在一套组件样式，6.23 接入后很可能出现两个类体系互相覆盖的情况。这种情况不可怕，但要提前知道，后面第 5 章有专门的处理办法。
我一般会先在本地起一个最小 demo 验证版本兼容性，而不是直接拷进大项目。因为大项目里构建链路复杂，一旦样式没生效，很难第一时间判断是组件问题还是工程问题。最小 demo 只需要一个空页面加一个按钮，跑通了再往大项目里搬。
2.2 最小接入：文件拷贝与入口注册
确认完上面三件事，就可以做最小接入。这里要强调一个习惯：先只拷贝组件源码和入口样式，不要把示例页面一起拷进去。示例页面的作用只是预览，不是生产资源，带上只会污染路由和增加构建扫描范围。
mkdir -p src/components/tw cp -r path/to/tailwindcss-components-6.23/src/components/* src/components/tw/ cp path/to/tailwindcss-components-6.23/src/components.css src/styles/tw-components.css命令细节：第一个命令建一个目录专门放这套组件，叫 tw 是便于区分；第二个命令把组件目录整体复制过去；第三个命令把组件入口样式复制到全局样式目录。把组件样式单独命名成 tw-components.css，而不是混进已有的 index.css，是为了以后升级或者停用的时候能一键移除。
接下来是入口注册。这一步必须按 Tailwind 主版本分开写，不能混用。如果项目是 v3，全局样式文件长这样：
/* src/styles/index.css */ @tailwind base; @tailwind components; @tailwind utilities; @import "./tw-components.css";如果项目是 v4，则改成：
/* src/styles/index.css */ @import "tailwindcss"; @import "./tw-components.css";逻辑说明：v3 写法里 @import "./tw-components.css" 必须放在 @tailwind utilities 之后。原因很简单：组件样式内部大量使用 @apply，而 @apply 在解析时需要依赖已经声明过的工具类。如果反了，构建时会直接报错。v4 写法里顺序同样有讲究，tailwindcss 在前，自定义组件样式在后，这样组件里如果要用 utilities 层的工具类，优先级是自然正确的。
参数说明：如果你的全局样式文件里已经引了其他 CSS，记住一个原则：越通用的越靠前，越具体的越靠后。基础工具类在前，组件级复合样式在后，这样业务页里写死的一些工具类才能正常压过组件默认样式。
2.3 验证是否生效：两条命令和一条肉眼规则
接入完成后，不要急着写业务，先验证。
npm run dev打开浏览器，随便找一个页面，插入一个最基础的按钮：
<button class="tw-btn tw-btn-primary tw-btn-md">验证按钮</button>如果页面上按钮有背景色、hover 变深，说明组件样式进入构建链了。如果按钮是光秃秃的黑字，说明组件样式没进来。这时候按下面的顺序排查。
第一，看入口 CSS 里那行 @import 有没有被编辑器自动纠正掉，尤其是 v4 工程里 CSS 语句顺序容易被打乱。第二，看构建日志有没有报错，比如找不到 tw-btn 之类的类。第三，清缓存重启 dev server，Tailwind 的增量缓存偶尔会吞掉新加的文件：
npx tailwindcss -i ./src/styles/index.css -o ./dist/out.css --watch跑完上面的命令再刷新页面，按钮样式还出不来，那就是配置文件或构建链路本身的问题，几乎可以排除组件集合的原因，回到 2.1 逐项核对。到这里，项目的接入工作完成。
3. 高频组件拆解：按钮、表单、弹窗的落地写法
接入只是第一步，真正天天打交道的是组件本身的写法。这一章挑三个最高频的场景拆开讲：按钮、表单、弹窗。这三个场景能覆盖后台系统里大部分页面，而且它们的类名组合方式是有规律的，掌握了规律，其他组件基本可以举一反三。
3.1 按钮体系：变体、尺寸、加载态的类名组合
按钮看起来简单，但它是最能体现一套组件方案设计水平的零件。6.23 的按钮写法遵循一个约定：基础类加变体类加尺寸类。基础类负责重置浏览器默认样式，变体类决定颜色风格，尺寸类控制内边距和字号。
<!-- 基础用法 --> <button class="tw-btn tw-btn-primary tw-btn-md">保存</button> <button class="tw-btn tw-btn-secondary tw-btn-md">取消</button> <button class="tw-btn tw-btn-danger tw-btn-md">删除</button> <button class="tw-btn tw-btn-outline tw-btn-md">导出</button> <!-- 加载态与禁用态 --> <button class="tw-btn tw-btn-primary tw-btn-md tw-btn-loading" disabled> 提交中 </button> <!-- 不同尺寸 --> <button class="tw-btn tw-btn-primary tw-btn-sm">小按钮</button> <button class="tw-btn tw-btn-primary tw-btn-md">中按钮</button> <button class="tw-btn tw-btn-primary tw-btn-lg">大按钮</button> <!-- 块级通栏按钮，常用于表单底部 --> <button class="tw-btn tw-btn-primary tw-btn-md w-full">登录</button>逻辑说明：tw-btn 是基座，统一把 border、outline、box-shadow、font 这些容易因浏览器不同而出现差异的属性归零。这样你后面叠加任何变体类，起点是一致的。tw-btn-primary 这类变体类内部通常由 @apply 组合出来，比如 @apply bg-primary text-white hover:bg-primary-hover active:bg-primary-active。
参数说明：变体类一共有五档，primary 是主操作，secondary 是次操作，danger 是危险操作，outline 是描边按钮，ghost 是只显示文字的弱化按钮。尺寸三档，sm 高度 32px 字号 14px，md 高度 40px 字号 14px，lg 高度 48px 字号 16px。这套高度体系跟表单输入框是对齐的，后面 3.2 会提到怎么让按钮和输入框站在一起时高度一致。
加载态的 tw-btn-loading 只做两件事：把光标变成禁止符号，并且让按钮里的文字位置保持稳定。实际转圈图标需要你自己加一个小 span，常见做法是在模板里加一个旋转动画类。图标旋转一般用一个 tw-animate-spin 这样的工具类，内部是 transform rotate 动画。
在 React 工程里写法要微调：
<button type="button" className="tw-btn tw-btn-primary tw-btn-md" onClick={handleSave} > 保存 </button>在 Vue 工程里写法则是：
<button type="button" class="tw-btn tw-btn-primary tw-btn-md" @click="handleSave"> 保存 </button>注意这里写 type="button" 的原因：按钮如果放在表单里不声明 type，默认是 submit，回车时会莫名其妙触发提交。这不是组件库的坑，是我在实际项目里遇到最多的按钮相关问题，每次都有人在这里浪费半天排查。
3.2 表单体系：输入框、下拉、校验错误的布局
后台系统里表单的占比极高，所以表单相关的类名组合值得仔细看。6.23 的表单类名不是把整个表单封装成一个大组件，而是把每一行表单项作为组合单元来提供，这样不同布局下你可以自由拼装。
<div class="tw-form-item"> <label class="tw-form-label" for="email">邮箱地址</label> <input id="email" type="email" class="tw-input tw-input-md w-full" placeholder="name@example.com" /> <p class="tw-form-error">请输入合法的邮箱地址</p> </div> <!-- 横向排列的表单项 --> <div class="tw-form-item tw-form-item-horizontal"> <label class="tw-form-label tw-form-label-fixed" for="nickname">昵称</label> <input id="nickname" type="text" class="tw-input tw-input-md flex-1" placeholder="最多 12 个字符" /> </div>逻辑说明：tw-form-item 负责一个 label 加一个控制项加一条错误信息之间的垂直间距。tw-form-label 统一字号、加粗和与输入框的距离。tw-input 是输入框基座，包含边框颜色、聚焦时的环、占位符颜色和禁用态。tw-form-error 默认隐藏还是显示，取决于类名是否出现，所以业务里可以用 v-if 这类条件渲染控制错误信息。
参数说明：tw-form-item-horizontal 是横向排列用的，适合那种左侧 label、右侧输入的窄表单。tw-form-label-fixed 让 label 固定宽度，这样多行表单的 label 能对齐。
校验错误通常这样组合：
<div class="tw-form-item"> <label class="tw-form-label" for="password">密码</label> <input id="password" type="password" class="tw-input tw-input-md w-full tw-input-error" placeholder="至少 8 位" /> <p class="tw-form-error">密码长度不够</p> </div>这里的 tw-input-error 是给输入框加红边框和红色聚焦环，tw-form-error 是红色小字。两者是独立的，你可以只加红字不加红框，也可以两个一起上。我的建议是让用户能明确感知错误发生在哪个输入框，所以红框比红字更重要，至少要有一个，否则用户摸不着头脑。
下拉框的类名套路一样：
<select class="tw-select tw-select-md w-full"> <option value="">请选择城市</option> <option value="city-a">城市 A</option> <option value="city-b">城市 B</option> </select>参数说明：tw-select 与 tw-input 的高度体系一致，这样下拉和输入框并排时不会出现一高一矮的尴尬。在 Vue 里 select 用 v-model，React 里是 value 加 onChange，样式层完全不用管状态。
3.3 弹窗与反馈：固定定位、层级与动画
弹窗是 6.23 里结构比较固定的部分，也是新手最容易翻车的地方。样式不生效很多时候不是类名写错，而是 fixed 定位和父级 overflow 之间的相互作用。
<div class="tw-modal-overlay tw-modal-fade" id="confirmOverlay"> <div class="tw-modal-content tw-modal-content-sm"> <div class="tw-modal-header"> <h3 class="tw-modal-title">确认删除？</h3> </div> <div class="tw-modal-body"> <p>删除后不可恢复，确定要继续吗？</p> </div> <div class="tw-modal-footer"> <button class="tw-btn tw-btn-secondary tw-btn-md">取消</button> <button class="tw-btn tw-btn-danger tw-btn-md">确认删除</button> </div> </div> </div>逻辑说明：tw-modal-overlay 一般被定义成 fixed inset-0 加半透明背景，z-index 由主题配置统一分配。tw-modal-content 负责把弹窗内容居中，内部再分三段：header 是标题栏带底部边框，body 是滚动区域，footer 是操作区带顶部边框。尺寸分三档：sm 最大宽 400px，md 是 560px，lg 是 720px。
参数说明：显隐控制在 overlay 上通过一个隐藏类实现，比如 tw-modal-hidden 就是 display: none。这样一来你要开关弹窗，只需要用 JS 切换这个类，不需要引入额外的弹窗库。隐藏类的命名在主题文件里可以自行修改，保持全站一致就行。
点击遮罩关闭的需求，需要监听 overlay 的 click 事件，并且判断事件目标：
const overlay = document.getElementById('confirmOverlay'); overlay.addEventListener('click', (e) => { if (e.target === overlay) { overlay.classList.add('tw-modal-hidden'); } });逻辑说明：这里必须判断 e.target === overlay，否则你点弹窗内容也会触发关闭。这个 bug 在真实项目里很常见，经常被当成组件库的问题报上来。动画方面，6.23 默认在 overlay 上挂一个 tw-modal-fade 类，原理是对 opacity 做过渡。想用缩放效果的可以把 fade 换成 tw-modal-zoom。如果要在弹窗里做长列表滚动，body 区要设置 max-height 加 overflow-y: auto，组件默认不会代劳。
4. 定制主题：把默认配色改成自己产品的设计令牌
把 6.23 接入项目之后，第一件要做的事往往不是写页面，而是把默认的蓝色主题改成自己产品的颜色。6.23 的主题入口和 Tailwind 本身一致：v3 在 tailwind.config.js 的 theme.extend 里，v4 在 CSS 的 @theme 块里。下面两种写法按版本二选一。
4.1 设计令牌：颜色、圆角、间距从哪里改
v3 写法：
// tailwind.config.js module.exports = { content: ['./src/**/*.{html,js,vue,jsx}'], theme: { extend: { colors: { primary: { DEFAULT: '#2f6bff', hover: '#1f55e8', active: '#1746c7', }, danger: { DEFAULT: '#dc2626', hover: '#b91c1c', }, success: { DEFAULT: '#16a34a', hover: '#15803d', }, }, }, }, };v4 写法：
@theme { --color-primary: #2f6bff; --color-primary-hover: #1f55e8; --color-primary-active: #1746c7; --color-danger: #dc2626; --color-danger-hover: #b91c1c; --color-success: #16a34a; --color-success-hover: #15803d; }逻辑说明：改主题的核心不是直接改颜色值，而是先搞清楚组件里到底引用了哪些令牌。6.23 的按钮变体类比如 tw-btn-primary 内部是用 @apply bg-primary text-white hover:bg-primary-hover 组合的，所以你把 primary 和 primary-hover 换掉，全站按钮的颜色就跟着换完了。反过来，如果你在组件 CSS 里搜不到 primary 这个令牌，说明这套组件的命名体系不一样，先搜索再动手，不要凭感觉改。
参数说明：改主题时我强烈建议只动 extend，不要去覆盖 Tailwind 默认的整个 colors 表。不要写成：
theme: { colors: { primary: '#2f6bff', }, }这样写会把 colors 整个替换掉，Tailwind 自带的 slate、gray 这些色板就全没了。实际项目里总会突然需要用到默认色板，到时再后悔就晚了。
间距、圆角、阴影也是同样的思路。如果组件里写着 rounded-lg，那 6.23 的组件默认用的就是 Tailwind 的 lg 圆角，你在 extend 里把 borderRadius 的 lg 改了，所有组件的圆角都会跟着变。这样改的收益很直接：设计给一套新圆角规范，你只动一个配置点。
4.2 组件覆盖：是改源码还是用 extend
全局主题定制之外，经常会有只针对某个页面的覆盖需求。比如登录页的按钮要比全局的大一圈，或者特定模块的卡片需要去掉阴影。这种场景有三条路，优先级从高到低。
第一条路是直接加辅助工具类。6.23 的复合类本身也是 CSS 类，和普通工具类优先级一样，没有特殊加成。
<button class="tw-btn tw-btn-primary tw-btn-md !px-10 !py-4 text-base" > 超大按钮 </button>逻辑说明：! 开头是 Tailwind 的 important 修饰符，生成的样式带 !important，能保证压过组件复合类里的 padding。这套做法适合一次性覆盖，简单直接。但注意不要到处滥用，每加一个 important 都是留一笔技术债。
第二条路是提升为设计令牌。如果发现在三个页面里都在做同一种覆盖，比如都是把按钮加高加宽，那就回到 4.1，把这种新的尺寸定义成一个语义化的尺寸变体，比如 tw-btn-xl，然后在按钮组件的 CSS 里补一段：
.tw-btn-xl { @apply px-10 py-4 text-base h-14; }参数说明：把覆盖从页面级提升到组件级，最大的好处是后续调整只改一处。这是我最推荐的做法，既不用顶着 important 的隐患，也不用去动组件源码。
第三条路是改组件源码。真的走到这一步，说明组件集合的默认设计跟你的产品差距太大，或者你 fork 了这套组件准备长期维护。如果是后者，我建议 fork 后把命名空间整体改掉，比如 tw-btn 改成 ya-btn，避免以后版本升级时和上游的类名冲突。这个思路在 5.5 里还会提到。
4.3 深色模式的接入方式
6.23 对深色模式的支持通常依赖 Tailwind 自带的 dark: 变体。前提是把 darkMode 配置成 class，让深色模式的触发由你自己控制，而不是跟随系统。
v3 配置：
module.exports = { darkMode: 'class', };v4 配置：
@variant dark (&:where(.dark, .dark *));逻辑说明：配置好之后，组件里要写双份类名。比如一个卡片，浅色下是白底，深色下是深灰底：
<div class="tw-card bg-white dark:bg-slate-800"> <!-- 内容 --> </div>实际操作里，我不建议把大量 dark: 都堆在组件类名里，代码会变得很难读。更常用的做法是把深色模式下需要覆盖的复合类集中写到一个 dark.css 里，等 html 根节点加上 dark 类时整体切换。
参数说明：如果你的设计稿里深色模式不是单纯反色，而是换了明度和饱和度，dark: 就够用。但如果你只是想白底变黑底、黑字变白字，建议直接用 CSS 变量方案，把所有背景和文字颜色改成 var(--bg-primary)、var(--text-primary) 这类变量，然后只在 html 上加一个 dark 类，CSS 变量整体切换。这样做体积更小，而且不会因为漏写某个 dark: 出现局部刺眼的白色。
5. 避坑：6.23 里最常见的 5 个翻车现场
组件方案用久了，你会发现大部分问题不是出在组件本身，而是出在接入方式和工程配置上。这一章把我在实际项目里遇到最多的 5 个问题整理出来，每条都按现象、原因、解决的顺序写，照着排查能省不少时间。
5.1 组件样式时灵时不灵：类名冲突排查
现象：同一个按钮组件，在页面 A 正常，在页面 B 里间距不对、背景色被替换。
原因：页面 B 里存在同名的全局类，或者页面 B 引入的某个 UI 片段里也定义了 .tw-btn 相关样式，加载顺序靠后的把先加载的覆盖了。这类问题在混合了多套 UI 方案的后台模板里尤其常见。
解决：按顺序排查。第一步打开 DevTools，选中按钮，看 Computed 面板里实际生效的样式来自哪个文件哪一行。第二步在项目里全局搜索 .tw-btn 同名类，确认是不是存在第二处定义。第三步如果确认是冲突，给这套组件加一个命名空间前缀，把最外层容器加上 tw-scope，并把组件样式从 .tw-btn 改成 .tw-scope .tw-btn。这样即使别的库也有同名类，也不影响你的组件。加命名空间要在配置文件里统一处理，不要手动去每个模板补。
5.2 改主题不生效：配置加载顺序
现象：tailwind.config.js 里改了 primary，按钮颜色纹丝不动。
原因：三个常见原因。第一，dev server 没重启，Tailwind 对配置文件的变更需要重新构建，增量缓存偶尔不认新配置。第二，项目里有多个配置文件，实际加载的不是你改的那个，这种情况在 monorepo 里尤其常见。第三，v4 工程里配置文件已经不作为主要入口，你改了 JS 配置但入口 CSS 还是旧写法，配置根本没被读取。
解决：先确认配置入口。v3 看根目录 tailwind.config.js，v4 看全局 CSS 里的 @theme。然后重启 dev server 并清缓存。还是不生效就在入口 CSS 末尾临时加一行：
.tw-btn-primary { background-color: red; }能变红说明主题没读到，不能变红说明整个组件样式都没进入构建链，问题在接入环节，回到第 2 章查全局样式文件的引入。
5.3 构建后体积暴涨：组件引用的收窄
现象：接入前产物 300KB，接入后变成 900KB。
原因：最常见的接法是把整个 components.css 全量 import，里面包含了全部按钮、表单、布局、反馈类。如果你的业务只用了其中一半，剩下的一半就在白白垫体积。另一个原因是 Tailwind 的扫描范围被扩得过大，把组件库里所有示例页面的类名也扫进去了，生成了大量用不到的样式。
解决：第一，按需引入。6.23 的组件通常每个模块一个文件，把全量 import 改成按页面或按模块 import。第二，检查 content 配置，确保它只扫描实际业务代码。v4 里用 @source 指令来限定扫描范围，v3 里检查 content 数组。改完后对比一下构建体积，通常能直接瘦掉三成。
5.4 弹窗被截断：overflow 与 z-index
现象：弹窗在部分页面上显示不全，下半部分被切掉，或者被顶部导航压住。
原因：第一，弹窗遮罩层用了 fixed 定位，但它的某个祖先节点存在 transform 或 filter，这时候 fixed 会相对那个祖先定位，而不是视口，于是弹窗位置跑偏甚至被 overflow: hidden 截断。第二，z-index 不够，被页面上其他元素压在下面。
解决：检查组件的所有祖先节点上有没有 transform、filter、perspective 这些属性，有就去掉，或者把弹窗直接挂到 body 下作为独立节点。层级问题需要全站统一约定：遮罩 z-50，导航栏 z-40，下拉菜单 z-30。按这个梯队分配，基本不会出现互相压住的情况。不要养成到处写 z-index: 9999 的习惯，后患无穷。
5.5 升级后布局错乱：版本差异导致的间距变更
现象：从旧版本升到 6.23 后，部分卡片和表单的间距变大或变小。
原因：组件库里某些间距类从 px 改成了 rem，或者默认间距令牌被调整，差异通常只有 4px 左右，肉眼很难在开发时看出来，但上线后用户会觉得页面不对劲。
解决：升级前先做一次视觉回归。不用复杂的自动化，最土的办法是把核心页面截图存下来，升级后逐张对比。对比时重点关注三个位置：按钮高度、表单 label 与输入框间距、卡片内边距。这三个位置是组件库最容易动的地方。如果发现是全局间距变化，回到主题配置里统一调 --spacing 相关令牌，不要手动去每个页面补 class，否则下次升级还会再炸一次。
6. 进阶：把高频组件固化成自己的复用资产
6.23 用顺手之后，会进入一个新的阶段：你会在项目里反复复制同一段类名组合。这时候真正的价值不在组件库本身，而在于能不能把高频组合固化成你自己的东西。
常见的做法有两种。第一种是用 @apply 把常用组合抽成新的复合类，比如项目里上传按钮出现频率极高，就把整套类名抽成 .upload-trigger。第二种是用框架抽象，Vue 里包一层组件，React 里拆一个组件，把类名封装在内部，业务侧只传 props。我强烈推荐第二种，原因是 @apply 抽出来的类在遇到状态切换时要写很多变体，而框架组件天然支持 props 和插槽，扩展性完全不同。
固化之前先列清单。我的做法是在项目里搜类名组合出现的次数，同一个组合出现三次以上就值得抽。比如卡片加 hover 阴影加标题栏这个组合，后台列表页面到处都是，抽成一个 Card 组件后，改圆角只需要改一个文件。
// Button.jsx export default function Button({ children, variant = 'primary', size = 'md', ...props }) { return ( <button type="button" className={`tw-btn tw-btn-${variant} tw-btn-${size}`} {...props} > {children} </button> ); }<!-- UploadTrigger.vue --> <template> <button type="button" class="upload-trigger tw-btn tw-btn-outline tw-btn-sm"> <slot /> </button> </template>逻辑说明：这个封装看起来简单，但它把变体名和尺寸名收敛到了组件接口层，业务里再也不用记一堆类名。后续如果要换主题，或者升级组件库，只改这个文件就行。
封装完成后的验证有三步：第一，浅色深色两种主题下各看一眼，确认颜色和间距都正常；第二，键盘 Tab 走一遍，确认焦点环还在，这对后台系统很重要；第三，把组件文档里标记的禁用态、加载态、错误态全部跑一遍，确认状态类没有漏掉。
我在这个环节吃过一次亏。当时为了图省事，把所有组件的类名塞在同一个 index.css 里，结果后面要拆分主题时发现类之间互相引用，拆了三天才拆干净。现在我的习惯是每个组件独立文件、独立命名空间，哪怕写的时候多花十分钟，也绝不给以后留拆不动的债。如果你打算长期维护这套组件方案，这个习惯越早养成越好，希望这些经验能帮到你。
本文还有配套的精品资源，点击获取
