1. 从一次组件库构建耗时说起cnfast 到底在解决什么问题如果你最近在折腾 shadcn/ui 或者任何基于 Tailwind 的组件库大概率会在某个 issue 或者讨论帖里看到cnfast这个名字。我第一次注意到它是因为一个中型后台项目里cn()这个工具函数被调用的次数远超我的预期——几乎每个组件的className合并都要走一遍。当时构建一次 Storybook 要等将近四十秒热更新也有肉眼可见的延迟于是我开始认真研究这个被无数人当作“理所当然”的小函数以及那个号称能带来数倍加速的替代方案。先把结论摆在前面cnfast并不是什么黑魔法它做的事情本质上是对clsx加tailwind-merge这套经典组合的一次针对性重写。要理解它为什么可能快得先搞清楚原来的cn()到底慢在哪里。绝大多数项目里的cn长这样import { clsx, type ClassValue } from clsx import { twMerge } from tailwind-merge export function cn(...inputs: ClassValue[]) { return twMerge(clsx(inputs)) }这段代码逻辑非常清晰clsx负责把各种形式的输入字符串、数组、对象、条件表达式拍平成一个类名字符串twMerge再负责解决 Tailwind 类名之间的冲突比如px-2 px-4最终只保留px-4。问题就出在第二步。tailwind-merge为了保证正确性内部维护了一套相当庞大的配置涵盖所有 Tailwind 的类名分组、修饰符、任意值语法等等。每次调用它都要做一遍解析、分组、冲突检测这个开销在单次调用时微不足道但当你的组件树里有成百上千个节点、每个节点都调用一次cn时累积起来就相当可观了。cnfast的切入点就在这里。它没有去改 Tailwind 的语义而是把tailwind-merge里那些“每次调用都要重新算一遍”的东西提前算好、缓存起来同时精简了输入解析的路径。换句话说它赌的是这样一个事实在一个真实项目里cn()被调用时传入的类名组合绝大多数是重复的或者高度相似的。这个假设在组件库场景下几乎总是成立因为同一个组件在不同状态下渲染的类名集合是有限的。所以当有人问“React 中的 7 倍加速是真的吗”我的第一反应是这个数字大概率来自某个特定 benchmark而且很可能是在大量重复调用的微基准测试里测出来的。它不代表你的整个应用会快 7 倍但它确实指向了一个真实存在的性能浪费点。接下来我会把这套东西拆开从原理、实测方法、适用边界到落地时的坑一层层讲清楚。2. cn() 的性能账本clsx 与 tailwind-merge 各自的开销在哪2.1 clsx 其实很便宜真正的成本在合并阶段很多人一看到性能问题第一反应是“是不是 clsx 太慢了”。实测下来clsx本身的开销小到可以忽略。它的核心逻辑就是遍历输入、判断类型、拼接字符串没有正则没有复杂的数据结构操作。在一个循环里跑十万次clsx耗时通常在几十毫秒量级。真正吃时间的是twMerge。tailwind-merge的工作流程大致是这样的先把传入的类名字符串按空格切分然后对每一个类名做解析识别出它的“组”比如padding-x、text-color、display再根据组内的优先级规则决定保留哪一个。这个解析过程涉及大量的字符串匹配和配置查找。它内部有一个叫config的对象里面定义了所有 Tailwind 类名的分组规则、冲突规则、修饰符处理方式。每次调用twMerge都要拿这个 config 去比对。这里有个关键点tailwind-merge的 config 是静态的但它的解析结果是动态计算的。也就是说哪怕你连续两次传入完全相同的类名字符串它也会老老实实重新解析两遍。这就是浪费的根源。2.2 一个容易被忽略的事实大部分 cn() 调用是重复的我在自己的项目里做过一个粗糙的统计在一个包含约 120 个组件的 Storybook 里页面加载过程中cn()被调用了大约 8000 次但其中不同的输入组合只有不到 400 种。也就是说超过 95% 的调用是在重复计算同样的结果。这个比例在组件库场景下非常典型因为组件的类名组合是由 props 和状态决定的而 props 和状态的取值空间是有限的。这就引出了一个很自然的优化思路既然输入重复率这么高为什么不把结果缓存起来cnfast的核心策略之一就是做这件事。它用一个 Map 或者类似的结构把“输入签名”映射到“合并后的结果”命中缓存就直接返回跳过整个解析流程。这个思路本身不新鲜很多性能优化都是这么干的关键在于缓存的键怎么设计、缓存怎么清理、命中率能到多少。2.3 7 倍这个数字是怎么来的微基准与真实场景的差距网上流传的“7 倍加速”通常来自这样的测试构造一个固定的类名数组在一个 tight loop 里调用cn和cnfast各十万次然后比较总耗时。在这种场景下缓存命中率接近 100%cnfast几乎只做了一次哈希查找而cn每次都完整跑一遍解析差距自然被放大。7 倍甚至更高都不奇怪。但真实应用不是 tight loop。你的组件渲染有 React 的调度开销、有 DOM 操作、有事件处理cn()只是其中很小的一环。所以更诚实的说法是cnfast能把你花在类名合并上的时间减少一个数量级但这个时间在你的总渲染时间里可能只占百分之几。它的价值不在于让应用“快 7 倍”而在于消除一个不必要的、随组件规模线性增长的浪费。当你的组件库大到一定程度这个浪费会变得不可忽视。提示如果你只是做一个小型项目组件数量在几十个以内cn()的性能开销基本感知不到没必要为了这点优化引入额外的依赖和复杂度。优化的收益和项目规模是强相关的。3. 拆解 cnfast 的实现思路缓存、预计算与输入路径精简3.1 缓存键的设计为什么不能简单用字符串拼接最直觉的缓存方案是把输入参数直接JSON.stringify或者拼接成字符串当键。但这里有个坑cn的输入类型是ClassValue它可以是字符串、数字、数组、对象甚至嵌套的数组。不同的输入结构可能产生相同的类名结果但序列化后的字符串不同这会导致缓存命中率下降。更麻烦的是对象里的键顺序不同、数组嵌套层级不同都会影响序列化结果。cnfast在这块的处理思路是先把输入规范化成一个稳定的字符串表示再拿这个表示去做键。规范化的过程其实和clsx做的事情有重叠所以它相当于把clsx的逻辑内联进来避免了一次函数调用和中间对象的创建。这个细节看起来小但在高频调用下减少一次函数调用和一次数组分配都是有意义的。另一个要考虑的是缓存的大小。如果无限制地往 Map 里塞内存会持续增长。实际项目里不同的类名组合数量是有限的所以通常不需要复杂的 LRU 策略但如果你在做的是一个长期运行、动态生成类名的场景比如某些低代码平台就得考虑加一个上限或者定期清理。3.2 预计算把能提前做的事都提前做tailwind-merge的 config 里有很多信息是可以在模块加载时就确定下来的比如每个类名组的匹配规则、组之间的冲突关系。cnfast会把这些预计算的结果缓存起来避免每次调用都重新构建。这部分的优化对首次调用之后的每一次调用都有收益。还有一个更激进的思路是预生成一个查找表。因为 Tailwind 的类名空间是相对固定的理论上可以把所有可能的类名组合的合并结果都算出来存成一张表。但这张表会非常大不现实。所以实际采用的是“按需缓存”只缓存实际出现过的组合。3.3 输入路径精简减少中间对象和函数调用在 V8 这类引擎里函数调用和对象分配都是有成本的。cn的原始实现里clsx(inputs)会创建一个数组twMerge内部又会创建若干中间对象。cnfast通过把逻辑合并到一个函数里减少了这些中间步骤。它可能直接在一个循环里处理输入边解析边判断冲突而不是先拍平再合并。这种“融合”式的实现方式在性能敏感的场景下很常见代价是代码可读性下降。你在读cnfast源码时会发现它比cn难懂得多各种位运算、查表、状态机混在一起。这是典型的用可维护性换性能。对于一个小工具函数来说这个 trade-off 通常是值得的因为它的行为是稳定的、测试覆盖充分的不需要频繁改动。对比维度cn (clsx tailwind-merge)cnfast输入解析每次调用完整解析规范化后查缓存冲突合并每次重新计算命中缓存直接返回中间对象较多精简代码可读性高较低适用规模任意中大型组件库收益明显4. 自己动手验证一套可复现的 benchmark 方法4.1 测试环境搭建别用在线沙箱本地跑才准网上很多 benchmark 是在 CodeSandbox 或者类似环境里跑的结果参考价值有限因为那些环境的 CPU 配额、JIT 状态都不稳定。要得到可信的数据最好在本地用 Node 跑关掉其他占资源的程序并且做多轮取中位数。我的做法是写一个简单的脚本分别 importcn和cnfast构造几组有代表性的输入然后跑循环。关键是要区分两种场景一种是“高重复率”即循环里反复传同样的输入另一种是“低重复率”每次传入不同的类名组合。这两种场景下的加速比会差很多前者可能十几倍后者可能只有一两倍甚至更少。import { cn } from ./cn import { cnfast } from cnfast const inputs [ [px-2 py-1, px-4, { text-red-500: true }], [flex items-center, justify-between, gap-2], // ... 更多组合 ] function bench(fn, iterations) { const start performance.now() for (let i 0; i iterations; i) { fn(...inputs[i % inputs.length]) } return performance.now() - start } // 预热 bench(cn, 10000) bench(cnfast, 10000) // 正式测试 const cnTime bench(cn, 100000) const cnfastTime bench(cnfast, 100000) console.log(cn: ${cnTime}ms, cnfast: ${cnfastTime}ms, ratio: ${(cnTime / cnfastTime).toFixed(2)})4.2 怎么解读结果关注绝对值别只盯着倍数跑完 benchmark 后你会得到一个倍数。但更有意义的是看绝对时间。如果cn跑十万次用了 200mscnfast用了 30ms那节省的 170ms 在十万次调用的尺度下才有意义。换算到单次调用cn是 2 微秒cnfast是 0.3 微秒。你的应用里如果有 5000 次调用节省的总时间大约是 8.5 毫秒。这个数字在大多数场景下是可以忽略的。所以我的建议是先测量你的应用里cn()到底被调用了多少次、总耗时占比多少。如果占比低于 1%那这个优化对你没意义。如果占比超过 5%那值得考虑。测量方法可以用 React DevTools 的 Profiler或者在cn里临时加一个计数器。4.3 在真实组件库中测量用 Profiler 而不是微基准微基准只能告诉你函数本身快了多少不能告诉你应用快了多少。要测真实收益得用 React DevTools 的 Profiler 录制一段交互看 commit 阶段的耗时变化。具体做法是先装原始cn录制一次再换成cnfast录制同样的交互对比两次的 commit 时间。这里要注意React 的 Profiler 本身有开销而且结果受很多因素影响所以要多录几次取平均。另外如果你的应用里有大量其他性能瓶颈比如不必要的重渲染、大列表没有虚拟化那cn的优化会被淹没你根本看不出来。这种情况下应该先解决更大的问题。注意不要在生产环境用console.time去测因为生产构建的代码经过压缩和优化函数名可能被混淆而且日志本身有开销。用 Profiler 或者专门的性能监控工具更靠谱。5. 落地时的取舍什么时候该换什么时候别折腾5.1 适合引入 cnfast 的三种典型场景第一种是组件库或设计系统项目。这类项目里cn()的调用密度极高而且类名组合重复率高缓存命中率能到 90% 以上收益最明显。第二种是大型后台应用组件数量多、页面复杂构建和热更新时的类名合并开销会累积。第三种是对包体积敏感的场景因为cnfast通常比clsx加tailwind-merge的组合更小如果你本来就在做 tree-shaking 优化它能帮你省下一些 KB。反过来如果你做的是一个小型营销页、一个原型 demo或者组件数量很少那引入cnfast的收益微乎其微反而增加了依赖管理的负担。还有一个容易被忽略的点cnfast的 API 兼容性。它需要和cn保持完全一致的行为包括对各种边界输入的处理。如果你在项目里用了比较冷门的 Tailwind 类名或者自定义的类名分组得确认cnfast的配置能覆盖到。5.2 迁移成本与风险API 兼容性、类型定义、测试覆盖迁移本身很简单通常就是把 import 换一下。但风险在于行为差异。tailwind-merge的版本更新会带来类名分组规则的变化cnfast如果跟进不及时可能导致某些类名合并结果不一致。这种 bug 很隐蔽因为大多数情况下结果是对的只在特定类名组合下才出问题。我的做法是迁移前先跑一遍现有的单元测试确保cn相关的测试都覆盖到了。然后写一个对比测试随机生成一批类名组合分别用cn和cnfast处理断言结果一致。这个测试可以跑几千组基本能覆盖常见的边界情况。如果发现不一致就去查是哪个类名分组的问题。类型定义方面cnfast应该导出和cn一样的ClassValue类型这样 TypeScript 项目不需要改任何类型标注。如果它的类型定义有出入记得在tsconfig里做好路径映射避免类型报错。5.3 一个折中方案只在构建时优化运行时保持原样如果你对cnfast的稳定性有顾虑还有一个折中方案在开发环境继续用cn在生产构建时通过别名替换成cnfast。这样开发时的行为完全可控生产环境享受性能收益。实现方式是在打包工具里配置 alias比如 Vite 的resolve.alias或者 webpack 的resolve.alias把/lib/utils指向不同的文件。这个方案的好处是风险隔离坏处是开发和生产行为不一致可能掩盖一些只在生产出现的问题。所以如果采用这个方案一定要在生产环境做充分的回归测试。我个人更倾向于直接统一使用因为cn这个函数的行为足够稳定只要对比测试通过风险是可控的。6. 那些文档不会告诉你的实操细节6.1 缓存失效的隐蔽陷阱动态类名与 HMR缓存方案最怕的是“输入相同但期望结果不同”的情况。在cn的场景下这通常不会发生因为合并规则是纯函数同样的输入永远得到同样的输出。但有一个例外如果你在运行时动态修改了 Tailwind 的配置或者用了某些会改变类名语义的插件那缓存就可能失效。这种情况很少见但如果你在做主题系统或者动态换肤得留意。另一个坑是 HMR热模块替换。在开发环境下模块被替换时缓存应该被清空否则你可能看到旧的类名结果。cnfast如果实现得当应该会在模块重新加载时重置缓存。但如果你自己包了一层或者做了持久化缓存就要手动处理这个问题。我遇到过因为缓存没清导致样式不更新的情况排查了半天才发现是缓存的问题。6.2 和 Tailwind 版本升级的配合配置同步问题tailwind-merge和 Tailwind 的版本是有对应关系的。Tailwind 每个大版本都可能调整类名分组规则tailwind-merge会跟进发布新版本。cnfast如果内置了自己的合并逻辑就需要同步跟进这些变化。如果你升级了 Tailwind 但cnfast没跟上就可能出现类名合并错误。我的建议是在package.json里把cnfast的版本锁定升级 Tailwind 时同步检查cnfast的更新日志。如果它长期不更新而你又需要新版本的 Tailwind 特性那就得考虑换回cn或者自己维护一个 fork。这个维护成本是引入cnfast时必须考虑的因素。6.3 团队协作中的沟通成本让同事理解为什么换技术选型不只是技术问题。你换了cnfast团队里其他人可能不知道继续按原来的方式写代码或者在 code review 时提出疑问。所以迁移时最好在项目文档里写清楚为什么换、收益是什么、注意事项有哪些。如果团队里有新人还得确保他们知道cn的实现在哪里不要从网上随便复制一个cn进来。还有一个实际问题是依赖审计。有些团队对第三方依赖有严格限制引入一个新包需要走审批流程。cnfast如果是个小众包可能过不了审计。这种情况下你可以考虑把它的核心逻辑内联到项目里作为一个内部工具函数。这样既享受了性能收益又避免了外部依赖。代价是你要自己维护这段代码跟进 Tailwind 的变化。7. 回到那个问题7 倍加速是真的吗我的答案是在特定的测量条件下是真的但它不是一个可以直接套用到你项目上的数字。cnfast确实解决了一个真实存在的性能问题也就是tailwind-merge在重复输入下的重复计算。它的优化思路是合理的实现也是有效的。但性能优化从来都是要看场景的脱离具体项目谈倍数没有意义。如果你正在维护一个中大型的组件库并且测量发现cn()的开销占比不低那cnfast值得一试。迁移成本不高收益在规模效应下会显现出来。如果你只是做个小项目或者应用里还有更大的性能瓶颈没解决那先把精力花在更重要的地方。工具是为人服务的不要为了用而用。我自己现在的做法是在新项目里默认用cnfast因为它足够稳定而且能省一点是一点。在老项目里如果没遇到明显的性能问题就不动它。毕竟能稳定运行的代码就是好代码优化要建立在测量的基础上而不是感觉上。 cnfast 替代 cn 函数：Tailwind 类名合并性能优化实践
1. 从一次组件库构建耗时说起cnfast 到底在解决什么问题如果你最近在折腾 shadcn/ui 或者任何基于 Tailwind 的组件库大概率会在某个 issue 或者讨论帖里看到cnfast这个名字。我第一次注意到它是因为一个中型后台项目里cn()这个工具函数被调用的次数远超我的预期——几乎每个组件的className合并都要走一遍。当时构建一次 Storybook 要等将近四十秒热更新也有肉眼可见的延迟于是我开始认真研究这个被无数人当作“理所当然”的小函数以及那个号称能带来数倍加速的替代方案。先把结论摆在前面cnfast并不是什么黑魔法它做的事情本质上是对clsx加tailwind-merge这套经典组合的一次针对性重写。要理解它为什么可能快得先搞清楚原来的cn()到底慢在哪里。绝大多数项目里的cn长这样import { clsx, type ClassValue } from clsx import { twMerge } from tailwind-merge export function cn(...inputs: ClassValue[]) { return twMerge(clsx(inputs)) }这段代码逻辑非常清晰clsx负责把各种形式的输入字符串、数组、对象、条件表达式拍平成一个类名字符串twMerge再负责解决 Tailwind 类名之间的冲突比如px-2 px-4最终只保留px-4。问题就出在第二步。tailwind-merge为了保证正确性内部维护了一套相当庞大的配置涵盖所有 Tailwind 的类名分组、修饰符、任意值语法等等。每次调用它都要做一遍解析、分组、冲突检测这个开销在单次调用时微不足道但当你的组件树里有成百上千个节点、每个节点都调用一次cn时累积起来就相当可观了。cnfast的切入点就在这里。它没有去改 Tailwind 的语义而是把tailwind-merge里那些“每次调用都要重新算一遍”的东西提前算好、缓存起来同时精简了输入解析的路径。换句话说它赌的是这样一个事实在一个真实项目里cn()被调用时传入的类名组合绝大多数是重复的或者高度相似的。这个假设在组件库场景下几乎总是成立因为同一个组件在不同状态下渲染的类名集合是有限的。所以当有人问“React 中的 7 倍加速是真的吗”我的第一反应是这个数字大概率来自某个特定 benchmark而且很可能是在大量重复调用的微基准测试里测出来的。它不代表你的整个应用会快 7 倍但它确实指向了一个真实存在的性能浪费点。接下来我会把这套东西拆开从原理、实测方法、适用边界到落地时的坑一层层讲清楚。2. cn() 的性能账本clsx 与 tailwind-merge 各自的开销在哪2.1 clsx 其实很便宜真正的成本在合并阶段很多人一看到性能问题第一反应是“是不是 clsx 太慢了”。实测下来clsx本身的开销小到可以忽略。它的核心逻辑就是遍历输入、判断类型、拼接字符串没有正则没有复杂的数据结构操作。在一个循环里跑十万次clsx耗时通常在几十毫秒量级。真正吃时间的是twMerge。tailwind-merge的工作流程大致是这样的先把传入的类名字符串按空格切分然后对每一个类名做解析识别出它的“组”比如padding-x、text-color、display再根据组内的优先级规则决定保留哪一个。这个解析过程涉及大量的字符串匹配和配置查找。它内部有一个叫config的对象里面定义了所有 Tailwind 类名的分组规则、冲突规则、修饰符处理方式。每次调用twMerge都要拿这个 config 去比对。这里有个关键点tailwind-merge的 config 是静态的但它的解析结果是动态计算的。也就是说哪怕你连续两次传入完全相同的类名字符串它也会老老实实重新解析两遍。这就是浪费的根源。2.2 一个容易被忽略的事实大部分 cn() 调用是重复的我在自己的项目里做过一个粗糙的统计在一个包含约 120 个组件的 Storybook 里页面加载过程中cn()被调用了大约 8000 次但其中不同的输入组合只有不到 400 种。也就是说超过 95% 的调用是在重复计算同样的结果。这个比例在组件库场景下非常典型因为组件的类名组合是由 props 和状态决定的而 props 和状态的取值空间是有限的。这就引出了一个很自然的优化思路既然输入重复率这么高为什么不把结果缓存起来cnfast的核心策略之一就是做这件事。它用一个 Map 或者类似的结构把“输入签名”映射到“合并后的结果”命中缓存就直接返回跳过整个解析流程。这个思路本身不新鲜很多性能优化都是这么干的关键在于缓存的键怎么设计、缓存怎么清理、命中率能到多少。2.3 7 倍这个数字是怎么来的微基准与真实场景的差距网上流传的“7 倍加速”通常来自这样的测试构造一个固定的类名数组在一个 tight loop 里调用cn和cnfast各十万次然后比较总耗时。在这种场景下缓存命中率接近 100%cnfast几乎只做了一次哈希查找而cn每次都完整跑一遍解析差距自然被放大。7 倍甚至更高都不奇怪。但真实应用不是 tight loop。你的组件渲染有 React 的调度开销、有 DOM 操作、有事件处理cn()只是其中很小的一环。所以更诚实的说法是cnfast能把你花在类名合并上的时间减少一个数量级但这个时间在你的总渲染时间里可能只占百分之几。它的价值不在于让应用“快 7 倍”而在于消除一个不必要的、随组件规模线性增长的浪费。当你的组件库大到一定程度这个浪费会变得不可忽视。提示如果你只是做一个小型项目组件数量在几十个以内cn()的性能开销基本感知不到没必要为了这点优化引入额外的依赖和复杂度。优化的收益和项目规模是强相关的。3. 拆解 cnfast 的实现思路缓存、预计算与输入路径精简3.1 缓存键的设计为什么不能简单用字符串拼接最直觉的缓存方案是把输入参数直接JSON.stringify或者拼接成字符串当键。但这里有个坑cn的输入类型是ClassValue它可以是字符串、数字、数组、对象甚至嵌套的数组。不同的输入结构可能产生相同的类名结果但序列化后的字符串不同这会导致缓存命中率下降。更麻烦的是对象里的键顺序不同、数组嵌套层级不同都会影响序列化结果。cnfast在这块的处理思路是先把输入规范化成一个稳定的字符串表示再拿这个表示去做键。规范化的过程其实和clsx做的事情有重叠所以它相当于把clsx的逻辑内联进来避免了一次函数调用和中间对象的创建。这个细节看起来小但在高频调用下减少一次函数调用和一次数组分配都是有意义的。另一个要考虑的是缓存的大小。如果无限制地往 Map 里塞内存会持续增长。实际项目里不同的类名组合数量是有限的所以通常不需要复杂的 LRU 策略但如果你在做的是一个长期运行、动态生成类名的场景比如某些低代码平台就得考虑加一个上限或者定期清理。3.2 预计算把能提前做的事都提前做tailwind-merge的 config 里有很多信息是可以在模块加载时就确定下来的比如每个类名组的匹配规则、组之间的冲突关系。cnfast会把这些预计算的结果缓存起来避免每次调用都重新构建。这部分的优化对首次调用之后的每一次调用都有收益。还有一个更激进的思路是预生成一个查找表。因为 Tailwind 的类名空间是相对固定的理论上可以把所有可能的类名组合的合并结果都算出来存成一张表。但这张表会非常大不现实。所以实际采用的是“按需缓存”只缓存实际出现过的组合。3.3 输入路径精简减少中间对象和函数调用在 V8 这类引擎里函数调用和对象分配都是有成本的。cn的原始实现里clsx(inputs)会创建一个数组twMerge内部又会创建若干中间对象。cnfast通过把逻辑合并到一个函数里减少了这些中间步骤。它可能直接在一个循环里处理输入边解析边判断冲突而不是先拍平再合并。这种“融合”式的实现方式在性能敏感的场景下很常见代价是代码可读性下降。你在读cnfast源码时会发现它比cn难懂得多各种位运算、查表、状态机混在一起。这是典型的用可维护性换性能。对于一个小工具函数来说这个 trade-off 通常是值得的因为它的行为是稳定的、测试覆盖充分的不需要频繁改动。对比维度cn (clsx tailwind-merge)cnfast输入解析每次调用完整解析规范化后查缓存冲突合并每次重新计算命中缓存直接返回中间对象较多精简代码可读性高较低适用规模任意中大型组件库收益明显4. 自己动手验证一套可复现的 benchmark 方法4.1 测试环境搭建别用在线沙箱本地跑才准网上很多 benchmark 是在 CodeSandbox 或者类似环境里跑的结果参考价值有限因为那些环境的 CPU 配额、JIT 状态都不稳定。要得到可信的数据最好在本地用 Node 跑关掉其他占资源的程序并且做多轮取中位数。我的做法是写一个简单的脚本分别 importcn和cnfast构造几组有代表性的输入然后跑循环。关键是要区分两种场景一种是“高重复率”即循环里反复传同样的输入另一种是“低重复率”每次传入不同的类名组合。这两种场景下的加速比会差很多前者可能十几倍后者可能只有一两倍甚至更少。import { cn } from ./cn import { cnfast } from cnfast const inputs [ [px-2 py-1, px-4, { text-red-500: true }], [flex items-center, justify-between, gap-2], // ... 更多组合 ] function bench(fn, iterations) { const start performance.now() for (let i 0; i iterations; i) { fn(...inputs[i % inputs.length]) } return performance.now() - start } // 预热 bench(cn, 10000) bench(cnfast, 10000) // 正式测试 const cnTime bench(cn, 100000) const cnfastTime bench(cnfast, 100000) console.log(cn: ${cnTime}ms, cnfast: ${cnfastTime}ms, ratio: ${(cnTime / cnfastTime).toFixed(2)})4.2 怎么解读结果关注绝对值别只盯着倍数跑完 benchmark 后你会得到一个倍数。但更有意义的是看绝对时间。如果cn跑十万次用了 200mscnfast用了 30ms那节省的 170ms 在十万次调用的尺度下才有意义。换算到单次调用cn是 2 微秒cnfast是 0.3 微秒。你的应用里如果有 5000 次调用节省的总时间大约是 8.5 毫秒。这个数字在大多数场景下是可以忽略的。所以我的建议是先测量你的应用里cn()到底被调用了多少次、总耗时占比多少。如果占比低于 1%那这个优化对你没意义。如果占比超过 5%那值得考虑。测量方法可以用 React DevTools 的 Profiler或者在cn里临时加一个计数器。4.3 在真实组件库中测量用 Profiler 而不是微基准微基准只能告诉你函数本身快了多少不能告诉你应用快了多少。要测真实收益得用 React DevTools 的 Profiler 录制一段交互看 commit 阶段的耗时变化。具体做法是先装原始cn录制一次再换成cnfast录制同样的交互对比两次的 commit 时间。这里要注意React 的 Profiler 本身有开销而且结果受很多因素影响所以要多录几次取平均。另外如果你的应用里有大量其他性能瓶颈比如不必要的重渲染、大列表没有虚拟化那cn的优化会被淹没你根本看不出来。这种情况下应该先解决更大的问题。注意不要在生产环境用console.time去测因为生产构建的代码经过压缩和优化函数名可能被混淆而且日志本身有开销。用 Profiler 或者专门的性能监控工具更靠谱。5. 落地时的取舍什么时候该换什么时候别折腾5.1 适合引入 cnfast 的三种典型场景第一种是组件库或设计系统项目。这类项目里cn()的调用密度极高而且类名组合重复率高缓存命中率能到 90% 以上收益最明显。第二种是大型后台应用组件数量多、页面复杂构建和热更新时的类名合并开销会累积。第三种是对包体积敏感的场景因为cnfast通常比clsx加tailwind-merge的组合更小如果你本来就在做 tree-shaking 优化它能帮你省下一些 KB。反过来如果你做的是一个小型营销页、一个原型 demo或者组件数量很少那引入cnfast的收益微乎其微反而增加了依赖管理的负担。还有一个容易被忽略的点cnfast的 API 兼容性。它需要和cn保持完全一致的行为包括对各种边界输入的处理。如果你在项目里用了比较冷门的 Tailwind 类名或者自定义的类名分组得确认cnfast的配置能覆盖到。5.2 迁移成本与风险API 兼容性、类型定义、测试覆盖迁移本身很简单通常就是把 import 换一下。但风险在于行为差异。tailwind-merge的版本更新会带来类名分组规则的变化cnfast如果跟进不及时可能导致某些类名合并结果不一致。这种 bug 很隐蔽因为大多数情况下结果是对的只在特定类名组合下才出问题。我的做法是迁移前先跑一遍现有的单元测试确保cn相关的测试都覆盖到了。然后写一个对比测试随机生成一批类名组合分别用cn和cnfast处理断言结果一致。这个测试可以跑几千组基本能覆盖常见的边界情况。如果发现不一致就去查是哪个类名分组的问题。类型定义方面cnfast应该导出和cn一样的ClassValue类型这样 TypeScript 项目不需要改任何类型标注。如果它的类型定义有出入记得在tsconfig里做好路径映射避免类型报错。5.3 一个折中方案只在构建时优化运行时保持原样如果你对cnfast的稳定性有顾虑还有一个折中方案在开发环境继续用cn在生产构建时通过别名替换成cnfast。这样开发时的行为完全可控生产环境享受性能收益。实现方式是在打包工具里配置 alias比如 Vite 的resolve.alias或者 webpack 的resolve.alias把/lib/utils指向不同的文件。这个方案的好处是风险隔离坏处是开发和生产行为不一致可能掩盖一些只在生产出现的问题。所以如果采用这个方案一定要在生产环境做充分的回归测试。我个人更倾向于直接统一使用因为cn这个函数的行为足够稳定只要对比测试通过风险是可控的。6. 那些文档不会告诉你的实操细节6.1 缓存失效的隐蔽陷阱动态类名与 HMR缓存方案最怕的是“输入相同但期望结果不同”的情况。在cn的场景下这通常不会发生因为合并规则是纯函数同样的输入永远得到同样的输出。但有一个例外如果你在运行时动态修改了 Tailwind 的配置或者用了某些会改变类名语义的插件那缓存就可能失效。这种情况很少见但如果你在做主题系统或者动态换肤得留意。另一个坑是 HMR热模块替换。在开发环境下模块被替换时缓存应该被清空否则你可能看到旧的类名结果。cnfast如果实现得当应该会在模块重新加载时重置缓存。但如果你自己包了一层或者做了持久化缓存就要手动处理这个问题。我遇到过因为缓存没清导致样式不更新的情况排查了半天才发现是缓存的问题。6.2 和 Tailwind 版本升级的配合配置同步问题tailwind-merge和 Tailwind 的版本是有对应关系的。Tailwind 每个大版本都可能调整类名分组规则tailwind-merge会跟进发布新版本。cnfast如果内置了自己的合并逻辑就需要同步跟进这些变化。如果你升级了 Tailwind 但cnfast没跟上就可能出现类名合并错误。我的建议是在package.json里把cnfast的版本锁定升级 Tailwind 时同步检查cnfast的更新日志。如果它长期不更新而你又需要新版本的 Tailwind 特性那就得考虑换回cn或者自己维护一个 fork。这个维护成本是引入cnfast时必须考虑的因素。6.3 团队协作中的沟通成本让同事理解为什么换技术选型不只是技术问题。你换了cnfast团队里其他人可能不知道继续按原来的方式写代码或者在 code review 时提出疑问。所以迁移时最好在项目文档里写清楚为什么换、收益是什么、注意事项有哪些。如果团队里有新人还得确保他们知道cn的实现在哪里不要从网上随便复制一个cn进来。还有一个实际问题是依赖审计。有些团队对第三方依赖有严格限制引入一个新包需要走审批流程。cnfast如果是个小众包可能过不了审计。这种情况下你可以考虑把它的核心逻辑内联到项目里作为一个内部工具函数。这样既享受了性能收益又避免了外部依赖。代价是你要自己维护这段代码跟进 Tailwind 的变化。7. 回到那个问题7 倍加速是真的吗我的答案是在特定的测量条件下是真的但它不是一个可以直接套用到你项目上的数字。cnfast确实解决了一个真实存在的性能问题也就是tailwind-merge在重复输入下的重复计算。它的优化思路是合理的实现也是有效的。但性能优化从来都是要看场景的脱离具体项目谈倍数没有意义。如果你正在维护一个中大型的组件库并且测量发现cn()的开销占比不低那cnfast值得一试。迁移成本不高收益在规模效应下会显现出来。如果你只是做个小项目或者应用里还有更大的性能瓶颈没解决那先把精力花在更重要的地方。工具是为人服务的不要为了用而用。我自己现在的做法是在新项目里默认用cnfast因为它足够稳定而且能省一点是一点。在老项目里如果没遇到明显的性能问题就不动它。毕竟能稳定运行的代码就是好代码优化要建立在测量的基础上而不是感觉上。