为什么CSS变量命名推荐Kebab-case_遵循CSS代码规范

CSS变量名必须以--开头且仅支持kebab-case（小写+连字符），如--btn-primary-bg合法，--userName和--user_name非法；大小写敏感，JS交互需严格匹配字符串形式。

CSS变量名必须用--前缀，且不支持驼峰或下划线

CSS自定义属性（即CSS变量）的语法强制要求以--开头，后面只能跟标识符（identifier），而CSS规范中明确禁止在标识符里使用大写字母、空格、点号、括号等字符。这意味着：--user-name合法，--userName和--user_name都非法——浏览器会直接忽略它们。

常见错误现象：--mainColor在开发者工具里显示为“无效属性”，控制台无报错但样式不生效；--header_bg被静默丢弃，后续var(--header_bg)返回initial值。

• --后首个字符不能是数字（如--1col-layout非法）
• 连字符-是唯一被CSS原生允许的分隔符，且必须前后都有字母/数字（--btn-primary✅，--btn-❌）
• 大小写敏感：--Text和--text是两个不同变量，但--text才是可解析的合法形式

kebab-case与HTML/CSS生态天然对齐

CSS类名、属性名、伪类（如:first-child）、自定义元素（如my-button）全部采用小写+连字符风格。CSS变量沿用kebab-case不是“推荐”，而是保持命名一致性最省力的选择。

使用场景举例：你写了一个按钮组件，HTML里用<button class="btn--primary">，对应CSS里写.btn--primary { background: var(--btn-primary-bg); }——变量名和类名结构完全对应，查bug时一眼能定位。

立即学习“前端免费学习笔记（深入）”；

• 避免混用：不要在同一个项目里同时出现--btnPrimaryBg（非法）和--btn-primary-bg（合法），后者是唯一可行路径
• 工具链友好：PostCSS插件、CSS-in-JS库（如Emotion）默认按kebab-case解析变量，改用其他风格需额外配置转换逻辑
• VS Code等编辑器对--xxx-yyy-zzz有语法高亮和自动补全，对驼峰写法无识别

和JavaScript交互时的大小写转换陷阱

JS通过getComputedStyle或style.setProperty读写CSS变量时，变量名必须严格匹配CSS中声明的形式。但JS本身不支持连字符作为变量名，所以必须用字符串传入：

element.style.setProperty('--text-color', '#333'); // ✅ 字符串字面量element.style.setProperty('--textColor', '#333'); // ❌ CSS端根本不存在这个变量

容易踩的坑：有人试图在JS里用camelCase命名变量再转成CSS变量，比如：

• const textColor = '--text-color'; —— 正确，字符串封装
• const textColor = '--textColor'; —— 错误，CSS端无法识别
• 从JS对象解构赋值时硬套驼峰：const { primaryColor } = theme; → setProperty('--primaryColor', primaryColor) → 失效

文件名、URL、类名、变量名统一用kebab-case是最小认知成本方案

前端项目里，一个视觉模块往往横跨多个文件：CSS文件叫header-nav.css，HTML里class="header-nav"，JS里操作--header-nav-height，路由URL是/header-nav。全部用kebab-case意味着开发者不用在不同上下文间做任何脑内转换。

性能和兼容性影响几乎为零，但维护成本差异巨大：当某天要全局替换颜色主题，搜--header-nav就能精准命中所有相关变量、类、文件，而如果混用命名风格，就得分别搜headerNav、header_nav、header-nav三轮。

真正复杂的是团队协作时的历史包袱——比如老项目已存在--BGColor这种非法写法，它可能靠某些构建工具“悄悄修复”过，但升级浏览器或切换打包器后突然失效。这时候别修变量名，先查它实际有没有被CSS引擎解析成功。