直接拼接CSS Modules类名易出错，因哈希化后手动拼接易漏空格、插入undefined等；classnames通过自动过滤假值、支持计算属性键和混合参数，安全合并动态类名。
React中直接拼接CSS Modules类名为什么容易出错
因为CSS Modules会将类名哈希化，styles.button 和 styles['button--primary'] 是两个独立的字符串，手动用 + 或模板字符串拼接（比如 styles.button + ' ' + styles.active）看似可行，但一旦类名含特殊字符、动态条件增多或需要响应式开关，就极易漏掉空格、重复添加、或在 false 值时插入 "undefined" —— 浏览器解析时直接丢弃无效类名，样式不生效却无报错。
classnames库如何安全合并CSS Modules类名
classnames 的核心价值不是“写得短”，而是把布尔逻辑和对象键值映射交给它处理，避免手写条件分支。它对 false、null、undefined、0 自动过滤，只保留真值对应的类名。
使用场景：按钮状态切换、表单验证高亮、暗色模式适配、组件尺寸响应式控制等。
安装与基础用法：
立即学习“前端免费学习笔记（深入）”；
npm install classnames
在组件中导入并组合：
import styles from './Button.module.css';
import cx from 'classnames';
function Button({ isActive, size, disabled }) {
return (
<button
className={cx(
styles.button,
{ [styles['button--active']]: isActive },
{ [styles[`button--${size}`]]: size },
{ [styles['button--disabled']]: disabled }
)}
>
Click me
</button>
);
}
注意点：
-
styles.button直接传入，作为基础类名（始终存在） - 每个条件用对象字面量包裹，键是类名变量（必须用计算属性
[...]），值是布尔表达式 - 不要传入字符串如
'button--active'—— 这会绕过 CSS Modules，导致类名未被哈希，且无法享受类型提示或构建时校验
与原生对象展开语法对比：为什么不用 {...{[styles.xxx]: condition}}
有人尝试用对象展开替代 classnames，例如：
className={Object.assign(
{},
{ [styles.button]: true },
condition && { [styles.active]: true }
)}
这看似简洁，但有硬伤：
- 当
condition为false时，false && {...}返回false，Object.assign会把false当作源对象，触发隐式转换，结果不可控 - 无法处理数组形式的类名集合（比如多个响应式类需同时开关）
- 没有内置对
undefined键的防御 —— 若styles.xxx因拼写错误返回undefined，整个键变成undefined: true，最终生成无效类名 -
classnames内部做了标准化处理，支持嵌套数组、对象、字符串混合传入，扩展性更强
TypeScript下配合CSS Modules的类型安全写法
如果项目启用 TypeScript，建议为 styles 添加类型约束，避免拼写错误在运行时才暴露：
import type { CSSModuleClasses } from 'react-css-modules';
import styles from './Button.module.css';
// 或更简单：用 require（Webpack/Vite 默认支持）
const styles = require('./Button.module.css') as Record<string, string>;
此时 cx(styles.button, { [styles.invalidKey]: true }) 会在编辑器报错，而纯 JS 项目只能靠测试或运行时观察。
另外，classnames 本身已带完整类型定义，无需额外安装 @types/classnames（v2.3.0+）。
真正难的不是写对一次，而是维护几十个带多状态的组件时，让类名逻辑不随业务迭代腐化 —— 这时候 cx 提供的声明式结构，比一堆三元表达式更易读、更少副作用。
