twmerge 本质是语义化类名合并而非字符串去重，按变体维度分组、同组后值覆盖、自定义类需显式配置防误判，动态任意值需加语义标签或扩展配置。
类名冲突的本质是属性覆盖，不是字符串拼接
直接用 className={base + ' ' + override} 拼接 Tailwind 类名，等于把所有样式“平铺”到 DOM 上。但 CSS 属性本身不允许多值共存（比如 p-4 和 p-2 都设了 padding），浏览器最终只取一个生效——而这个“取哪个”，取决于构建时 CSS 文件里规则的顺序，和你在 JS 里写的先后无关。
所以问题不在“有没有加类”，而在“加了但没生效”。twMerge 不是去重字符串，而是识别语义：它知道 p-4 和 p-2 属于同一组（padding），且后者在参数中更靠后，就只保留 p-2。
- 它内置了完整的 Tailwind 类分组逻辑（如
spacing、colors、typography） - 对非 Tailwind 类（如
my-custom-class）默认放行，不做任何处理 - 不解析 CSS，纯 JS 字符串分析，零运行时依赖
响应式与伪类变体必须按维度隔离处理
你不能指望 twMerge('md:p-4 p-2 hover:p-3') 返回一个“混合结果”。它实际做的是三件事：分别处理 md: 下的 padding、普通上下文下的 padding、hover: 下的 padding——每组内部按“最后胜出”规则合并，组之间互不影响。
这意味着：
-
twMerge('p-2 md:p-4 p-6')→'p-6 md:p-4'（普通 p 被p-6覆盖；md:独立保留） -
twMerge('hover:bg-blue-500 focus:bg-red-500 hover:bg-green-400')→'focus:bg-red-500 hover:bg-green-400'（hover:组内后一个胜出，focus:单独存在） - 嵌套变体如
focus:hover:bg-gray-200会被识别为独立变体，不与hover:bg-合并
自定义类名被误判是最常见的 silent bug
如果你的项目有 text-2xs 或 bg-brand-primary 这类命名，twMerge 可能把它当成标准 Tailwind 类处理——因为前缀 text- 和 bg- 完全匹配其内置模式。结果就是 text-sm text-2xs 被压缩成 text-2xs，而你根本没意识到字体大小被悄悄替换了。
避免方式很直接：
- 给自定义工具类加明确前缀：
ui-text-2xs、theme-bg-brand - 完全绕过
twMerge处理自定义类：twJoin(twMerge(base), customClass) - 用
extendTailwindMerge显式声明哪些类属于你的主题，例如把text-2xs加入fontSize组并指定优先级
性能不是问题，但缓存失效点容易被忽略
twMerge 默认带 LRU 缓存（500 条），对固定字符串组合非常友好。但如果你传入动态生成的任意值类（如 text-[${size}px]），每次 size 变化都会产生新 key，缓存基本无效。
更隐蔽的问题是：当使用未标记的任意值时，比如 bg-[#1e293b] 和 bg-[linear-gradient(...)]，twMerge 可能因无法区分类型而错误合并。这时要主动加语义标签：
-
bg-[color:#1e293b]和bg-[image:linear-gradient(...)] - 或统一用
twMerge的扩展配置注册backgroundImage和backgroundColor分组
真正影响性能的从来不是 twMerge 本身，而是你把本该静态的类名写成高频率变动的模板字符串。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
