不能直接在 tailwind.config.js 中用 var(--primary) 作颜色值，因其为运行时字符串，Tailwind 构建时无法解析出 RGB 分量，导致色阶生成失败、hover 变体报错。
不能直接在 tailwind.config.js 里用 var(--primary) 当颜色值——它不会被解析成 RGB，后续变体（如 hover:bg-primary-600）会崩，构建时可能报 Cannot read property 'r' of undefined。
为什么 var(--x) 在 theme.extend.colors 里会失效
Tailwind 的颜色系统要生成 -50 到 -900 的色阶、透明度叠加、hover 暗化逻辑，所有这些都依赖对颜色值的静态解析。而 var(--primary) 是个运行时字符串，tailwind.config.js 加载时根本没执行 CSS，更拿不到变量真实值。
- 现象：写
primary: 'var(--primary)'后，bg-primary能出类，但bg-primary-500不生成，hover:bg-primary可能报错或渲染为color: rgb(NaN) - 根本原因：Tailwind 的
color插件调用parseColor()时，传入的是未求值的字符串，无法提取r/g/b分量 - 不是 bug，是设计限制：配置文件是 JS 上下文，不接入 CSS 运行时环境
正确映射 CSS 变量的两种实用路径
根据你要解决的问题选：静态复用？还是运行时切换？别混着来。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 如果你只是想把设计系统里固定的
--color-brand拿来当一个新色名用（比如text-brand），就别动var()，直接在theme.extend.colors里写死 HEX：brand: '#1677FF'。稳定、可推导变体、零 runtime 风险 - 如果你真需要深色模式切换、主题热更新（比如用户点按钮换主题），那就放弃在 config 里“映射”，改用
@layer utilities+:root变量绑定：@layer utilities { .text-brand { @apply text-[var(--color-brand)] ; } .bg-brand { @apply bg-[var(--color-brand)] ; } }然后在全局 CSS 或 HTML 的:root里定义--color-brand，JS 里用document.documentElement.style.setProperty()动态改 - 若坚持在 config 里“引用”变量（例如统一管理色值源头），必须确保变量已提前注入且拼写绝对正确，并用
rgb(var(--tw-brand))格式——但 Tailwind 不校验该变量是否存在，错一个字母就产出非法 CSS
用 @theme 规则声明并自动绑定变量（Tailwind v4+）
v4 开始支持原生 @theme at-rule，这是目前最干净的“CSS 变量即 Tailwind 类名”方案，无需手动写 utility。
立即学习“前端免费学习笔记（深入）”；
- 在你的主 CSS 文件（如
src/index.css）里写：@import "tailwindcss"; @theme { --color-primary: #1677FF; --color-success: #10b981; --radius-card: 8px; } - 保存后就能直接用：
text-primary、bg-success、rounded-card—— Tailwind 会自动识别--color-、--radius-等前缀并生成对应工具类 - 注意命名规则：
--color-→ 生成颜色类；--spacing-→ 间距；--radius-→ 圆角；--text-→ 字体大小；不按规则写（比如--my-color）就不会被识别 - 该方式仍要求变量在 CSS 解析时已存在，所以
@theme块必须放在@import "tailwindcss"后，且不能依赖 JS 动态注入的变量
真正容易被忽略的点是：你以为在 config 里写个 var() 就能“桥接”CSS 和 JS 配置，其实两者生命周期完全隔离。要么全静态（config 写死）、要么全动态（utility + setProperty），中间态看着省事，实际埋雷最多。
