css变量核心是绑定数值与设计意图，如--spacing-sm替代8px；需语义化命名、统一单位、集中定义；calc()不支持变量乘除，媒体查询和主题切换应分层覆盖变量。
用--spacing-sm代替8px，不是为了炫技
写margin: 8px没问题，但团队协作或半年后回看时，“8px到底代表什么？”会卡住你。CSS变量的核心价值是把数值和设计意图绑定，比如--spacing-sm明确表达“小间距”，而不是让人猜这个8px是不是按钮内边距、卡片间隔，还是弹窗阴影偏移。
实操建议：
- 变量名必须带语义前缀，如
--color-primary、--radius-md，避免--blue-500这类纯视觉命名（主题切换时会失效） - 所有尺寸类变量统一用
rem或em定义，别混用px，否则缩放或根字体变更时行为不一致 - 变量定义集中放在
:root里，不要分散在组件内部——否则无法被其他模块复用，也失去“单一数据源”意义
为什么calc()和CSS变量一起用容易出错
常见错误：写width: calc(var(--spacing-lg) * 2)，浏览器直接忽略整条声明——因为calc()不支持对变量做乘除运算，只接受加减和单位混合计算。
正确做法：
- 乘法/除法逻辑移到JS或构建时处理，CSS变量只存最终值，比如
--spacing-xl: 48px而非--spacing-base: 16px再算*3 - 必须动态计算时，用
clamp()或min()/max()替代calc()中的复杂表达式，它们对变量兼容性更好 - 调试时用
console.log(getComputedStyle(document.documentElement).getPropertyValue('--spacing-sm'))确认变量值是否被正确解析（注意返回带单位的字符串）
媒体查询里覆盖CSS变量，比写两套选择器更稳
很多人习惯这样写：@media (max-width: 768px) { .card { padding: 12px; } }，但一旦.card在多个地方用到不同间距，维护成本飙升。
换成变量方案更可靠：
- 在
:root定义默认值：--spacing-card: 24px - 在媒体查询里只改变量：
@media (max-width: 768px) { :root { --spacing-card: 16px; } } - 组件内始终用
padding: var(--spacing-card)，响应逻辑和样式彻底解耦 - 注意：变量覆盖必须写在
:root下，写成.mobile :root或html.mobile无效——CSS变量作用域只认伪类和媒体查询，不认自定义类
主题切换时，prefers-color-scheme和CSS变量配合的关键细节
直接写@media (prefers-color-scheme: dark) { :root { --color-bg: #1a1a1a; } }看似可行，但遇到用户手动切主题（比如系统是亮色，但网页强制暗色），这个媒体查询就失灵了。
更健壮的做法：
- 定义三层变量：基础层（
--color-bg-default）、系统层（--color-bg-system）、手动层（--color-bg-manual），用var(--color-bg-manual, var(--color-bg-system, var(--color-bg-default)))逐级回落 -
prefers-color-scheme只负责设置--color-bg-system，手动主题由JS写入document.documentElement.style.setProperty('--color-bg-manual', ...) - 别忘了给
transition加在变量依赖的属性上，比如background-color: var(--color-bg); transition: background-color 0.2s——变量本身不触发过渡
变量不是万能胶，它解决的是“命名混乱”和“重复硬编码”，但不会自动帮你理清设计系统层级。真正难的从来不是怎么写var(--xxx)，而是团队能否就--spacing-xs到底等于4px还是6px达成共识，并坚持不绕过它直接写死数值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
