背景
通常在 2C 的 H5 项目开发中，样式的要求会显著高于 2B 的 Web 端应用。这导致前端开发者在进行 H5 开发时需要手写比 2B 项目多的多的 CSS 样式。现在的年轻的前端开发者却大多不太重视 CSS 样式的编写，很多效果的实现方式也没有统一的标准，组件化样式的开发方式又会造成大量的样式冗余。虽然 CSS 的体积占比在现在的前端应用中已经很小了，但在前端性能逐渐内卷的今天，CSS 还是一个可以优化的地方。传统靠类名复用样式的 CSS 开发方式虽然可以减少 CSS 代码的冗余，但却会造成 CSS 代码的可维护性差，牵一发动全身的问题。
以 Tailwind CSS 为代表的原子化 CSS 框架就是应对上述问题的一个不错的解决方案，通过一套原子化的 CSS 类名，实现了对样式的快速复用，同时又可以保证可维护性。 CSS 的冗余也得到有效控制，在复杂度高的项目中更加明显。此外，这类框架也解决了 CSS 实现不标准的问题，帮助团队快速拉齐 CSS 水平，提高项目质量。
Tailwind CSS 简介
以下内容来自于 GPT
Tailwind CSS 是一种现代、高度响应性的 CSS 框架，标志性的特点是原子化的设计理念。原子化在这里意味着每一个工具类都对应着一个唯一的样式属性，可以单独使用，也可组合使用来描述一个元素的样式。通过组合一系列的基础类，开发者就可以完成原来编写 CSS 的工作，例如，控制元素间的边距、大小、颜色，可以使用如 bg-green-500、text-center、px-4 等原子化的类。这样的设计可以使得样式描述变得更加直观且富有表现力。Tailwind CSS 的原子化设计为开发者提供了极大的灵活性，节省了样式的复用和重写的时间。同时，这种原子设计让代码更易维护和更新，开发体验有很大优势。
优势
基础决定上层，原子化设计给 Tailwind CSS 带来了一系列优势，相比与 2B 的 Web 端应用，这些优势在 H5 可以更好的发挥。
打包体积
首先，Tailwind CSS 的原子化设计可以帮助我们减少重复的 CSS 代码。这个优点很好理解，在前组件库时代，共享样式的方式是通过相同的类名，Tailwind CSS 也是完全的一样的原理。只不过通常 Tailwind CSS 的一个类名只对应一个 CSS 样式，这样就解决了原来共享类名时，修改样式会影响所有有这个类名的元素的问题，也就是样式组件化解决的问题。由于类名的共享，CSS 代码的体积就自然变小了，并且越大的项目越明显，因为类名以线性速度增加时，类名组合以指数速度增加。
在我们的项目中，复杂度差不多的情况下，使用 Tailwind CSS 的页面需要加载的 CSS 体积相比基本没有使用的页面，会减小 50% 左右，这里两个页面还都加载了传统 CSS 方案的组件，如果全部使用 Tailwind CSS 方案效果会更明显一点。但需要注意的是，尽管减少的百分比很可观，但实际上减少的体积只有不到 5KB，对于当今的网速和页面需要的图片来说，这点节省的体积是几乎可以忽略。
开发体验
从我个人的体感来说，Tailwind CSS 更大的价值体现在 DX（开发者体验） 层面。
首先，使用 Tailwind CSS 可以几乎不用写 CSS 了，虽然这个工作变成了写原子类名，但对于开发者的心智负担的减少远比想象的大。开发时，开发者可以专注在一个文件中，不再需要在 ts 文件和 css/less/sass 文件间来回切换，大幅提高了开发者的集中度。而且开发者也不需要再为每个组件起类名了。过去，类名有很多作用，除了样式，比如 querySelector 也通常依赖类名，但现在，类名通常只用来描述样式，Tailwind CSS 让开发者不在需要只为了样式编一些稀奇古怪的类名，又节省了不少心智成本。此外，Tailwind CSS 十分灵活，自定义插件可以把一些常用的样式组合以插件的方式定义一个类名，在项目中方便的复用。
标准化
Tailwind CSS 的原子化设计，保证同样的样式实现方式一致。长久以来，CSS 质量难以控制的一个主要原因就是同样的视觉效果可以有多种实现方式。以盒模型为例，通常，内外边距甚至边框都可以用来实现元素周围的空白，然而，这就给控制代码质量带来了难题，毕竟，这个时代应该没有人会在 Code Review 的时候一行一行看 CSS 的实现了。Tailwind CSS 通过原子化的类名和 CSS 的搭配，保证了同样的视觉效果的 CSS 实现方式一定是相同，这极大的提高了 CSS 的标准化，侧面保证了 CSS 的质量。
可维护性
可维护性是 Tailwind CSS 的另一个优势。传统的 CSS 依赖类名共享的方式造成了样式复用和重写的复杂性，自 3 大框架带来组件化风潮以后，样式不再和类名绑定，而是和组件绑定，像 styled-components、css-module 等方案则更进一步，连类名都是 hash 生成的，保证了一个类只在一个地方使用，消除了样式复用的问题。
但如上文所说，这在对样式定制化要求高的 2C H5 应用可能造成大量的样式冗余。而 Tailwind CSS 通过原子类名和单一样式的映射关系，巧妙的解决了这个问题，同时没有引入额外的样式冗余。由于原子类名对应单一样式，也没有必要对原子类增加样式，从而保证了项目整体的 CSS 可维护性。
兼容性
Tailwind CSS 的底层是 PostCSS，PostCSS 本身就善于解决各种兼容性问题，Tailwind CSS 的高兼容性也遗传自此。需要时，开发者还可以使用 PostCSS 插件配合 Tailwind CSS，进一步增强 Tailwind CSS 的兼容性和扩展性。
劣势
然而，软件开发没有银弹，Tailwind CSS 同样有其不足之处。
局限性
首先，Tailwind CSS 有一些局限性。比如在涉及到伪类、伪元素时，使用 Tailwind CSS 编写就很不直观，也不方便。而伪类和伪元素又是 CSS 中常用的样式解决方案，比如 H5 经常使用的 0.5px 边框，就需要使用伪元素缩放来实现。虽然这个问题在 Tailwind CSS 中可以通过插件解决，但这毕竟增加了成本。Tailwind CSS 实现复杂的动画效果也比较痛苦，而这又是 H5 2C 应用一个常见的需求，官方给出的方式也是类似于插件的定制 theme 的方案，对于开发者来说不够友好。另外，由于 Tailwind CSS 的样式和原子类绑定，这导致在复写一些组件的已有样式时，很可能出现权重不够的情况，此时往往需要替代方案解决，侧面削弱了 Tailwind CSS 的优势。
额外配置
另一个问题是额外的配置开销。Tailwind CSS 虽然提供了高度的可定制性，但是这种灵活性通常需要付出一定的额外配置工作，如果没有良好的基础设施积累，这可能会增加项目的启动成本。此外，由于 Tailwind CSS 基于 PostCSS，如果项目中已经应用了一些 PostCSS 插件，Tailwind CSS 与其他插件（如 PostCSS，Autoprefixer 等）配合使用，可能会面临兼容性问题，需要额外的调整保证其正常运行。
团队推广
推广 Tailwind CSS 也通常会在团队中面临一些挑战。Tailwind CSS 的原子化类命名方式与传统的 CSS 写法有很大差异，可能需要一段时间的学习成本。一些开发者可能不愿意接受，这可能会影响到团队的接受度和使用效率。虽然目前常用的 VS Code 已经有了不错的插件降低 Tailwind CSS 的上手成本，但在人数较多的团队中，推广的成本在当前的大环境下依旧可能受到挑战。
总结
技术为业务服务，针对业务场景选择合适的技术方案可能永远都有更好的答案。在 2C H5 应用的业务场景中，个人体验下来，Tailwind CSS 的优势大于劣势，在开发效率、代码质量上都可以获得不错的提升，样式体积也能有一定缩小。虽然 Tailwind CSS 也存在一定问题，可能需要配合其他的方案，推广也有一定成本。但总的来说，在我们的 2C H5 项目中的首次应用还是得到了广泛的好评，也作为基础设施沉淀下来，争取在未来的项目中发挥更大的价值。
