必须用theme.extend.colors定义多套主题色（如passion/dignity/brand），每个顶层键唯一且不覆盖默认色盘；支持数字阶（50–900）或语义名（DEFAULT/light/dark）子键，但不可混用；动态换肤需配合CSS变量与bg-[var(--passion-900)]语法，预编译类名不响应运行时变化。
直接在 tailwind.config.js（或 tailwind.config.cjs）里用 theme.extend.colors 嵌套对象即可支持多套主题配色，无需插件、不改构建流程，但必须注意键名唯一性和 CSS 变量注入时机。
如何定义并区分多套主题色（如 passion/dignity/brand）
Tailwind 本身不内置“主题切换”逻辑，所谓“多套配色”本质是把不同语义的颜色组作为独立命名空间注册进 colors。例如：
module.exports = {
theme: {
extend: {
colors: {
passion: {
50: '253 238 248',
100: '247 216 237',
900: '112 0 64'
},
dignity: {
50: '235 244 253',
900: '0 28 84'
},
brand: {
DEFAULT: '#1e40af',
light: '#e0f2fe',
dark: '#0c4a6e'
}
}
}
}
}
这样你就能写 bg-passion-900、text-dignity-900、border-brand-dark 等类名。关键点：
- 每个顶层键（
passion、dignity）必须唯一，不能和默认色名（如blue、gray）冲突 - 子层级支持数字阶梯（
50–900）或语义名（DEFAULT、light），但不要混用同一组内两种风格 - 若某套色需用于
text-、bg-、border-等所有前缀，建议至少提供DEFAULT和一个深色（如900）或浅色（如50）变体
为什么不能直接覆盖默认 color palette？
覆盖（如把 blue 改成品牌蓝）看似简单，但会破坏依赖默认色的第三方组件（比如 daisyUI 的 btn-primary 默认绑 blue-600）。更严重的是：当你需要同时展示“热情红”和“庄严靛”两种视觉语义时，覆盖式修改会让它们无法共存。
立即学习“前端免费学习笔记（深入）”；
正确做法是保留默认调色板不变，只扩展新命名空间。Tailwind 的 extend 是合并逻辑，不是替换——这也是为什么你总该用 extend.colors 而非直接写 colors。
如何让这些配色在深色模式下自动适配？
Tailwind 本身不自动适配多套色的明暗变化；它只负责生成类名。真正的明暗切换要靠两层配合：
- CSS 变量层：在
:root和.dark中分别定义--passion-900、--dignity-900等变量，值按主题切换 - Tailwind 层：用
plugins或自定义content规则让类名能读取这些变量（例如bg-[--passion-900]）
但注意：bg-passion-900 这类预编译类名，其颜色值在构建时就固化为 RGB/HSL，不会响应 CSS 变量变化。所以如果你真需要动态主题切换，应优先走 CSS 变量 + bg-[--my-var] 路线，而不是依赖多套 extend.colors。
常见错误：配置后类名不生效
最常踩的坑是路径或格式问题：
- 用了
tailwind.config.js却在 ESM 项目里导出module.exports（应改用export default） - 颜色值写成十六进制但没加引号（
'#1e40af'✅，#1e40af❌） - 在
content配置中漏掉使用了新类名的文件路径，导致 PurgeCSS 删除了这些类 - 重启了开发服务器但没清除 Tailwind 缓存（可删
.next/cache或node_modules/.cache后重试）
多套配色本身不增加运行时负担，但每新增一个颜色变体，都会生成对应的所有工具类（text-、bg-、border-…），过度扩展可能拖慢构建速度。建议按需注册，别一次性塞满 10 套色系。
