autoUno：最直觉的UnoCSS预设方案

可能你跟我一样头一次听说原子化CSS时，觉得写预设 class 听起来是一件极蠢的事，感觉这是在开倒车，因为我们都经历过 Bootstrap（其实不属于原子化） 的时代。

于是在这个概念刚刚在国内爆火的时候，我对其是嗤之以鼻的，当时我想象中的原子化：

只有带鱼屏才装得下。

而实际上的原子化：

在实际使用中，我们往往不会将所有的样式都使用原子化实现（当然也可以这么干）。

举一个例子，在你开发时，你按照自己习惯，做了一个近乎完美的布局，你的 class 已经写的非常棒，页面看起来赏心悦目，而此时，产品告诉你要在某个按钮的下面加一句提示，为了不破坏你的完美代码，又或者是样式无需太多的 css，你可能会选择直接写行内样式。此时原子化的魅力就体现了出来，只需要简单的寥寥几字，就把准确的 css 表达出来了，而无需再抽出一个无意义的 class。

在 tailwindCSS、windiCSS 之后，一位长发飘飘的帅小伙，发布了一款国产原子化工具 UnoCSS。虽然大家可能很熟悉它，我还是想啰嗦几句。

CSS原子化在前端的长河中，可谓是一个婴儿：

“原子化 CSS”（Atomic CSS）的概念最早可以追溯到 2014 年，由 Nicolas Gallagher 在他的博客文章 “About HTML semantics and front-end architecture” 中提出。他在文章中提到了一种新的 CSS 方法论，即使用“单一功能类”（Single-purpose Classes）来替代传统的基于组件或块的样式管理方式。这种方法的核心思想是，将每一个 CSS 类设计为仅包含一种样式规则或一组简单的样式，以便更好地复用和组合样式，从而减少冗余代码。这一思想成为后来原子化 CSS 的基础。同年，第一个原子化框架 ACSS（Atomic CSS）发布了，由 Yahoo 团队开发。

ACSS 的推出激发了 Utility-First CSS 框架的兴起，最终在 Tailwind CSS 等项目中得到广泛应用。

Tailwind 和 Windi CSS 虽然也支持自定义，但它们的定制性主要体现在配置文件的扩展上，如自定义颜色、间距、字体、断点等，且在设计上仍然偏向于固定的原子类名体系。这两者可以通过配置文件生成新的实用类名，这种方式显然使他们有了不可避免的局限性。

而 UnoCSS 则有着高度定制化的特性，主要体现在它的灵活性和插件化设计，使其可以自由定义和扩展类名、行为，甚至能模拟其他 CSS 框架。相比之下，Tailwind CSS 和 Windi CSS 在设计上更偏向于固定的、基于配置的实用类体系，而 UnoCSS 则提供了更多自由度。

这样的设计也使得 UnoCSS 有着天然的性能优势，UnoCSS 支持基于正则表达式的动态类名解析，允许开发者定义自定义的样式规则。例如，可以通过简单的正则规则为特定样式创建动态的类，而不需要预先定义所有的类名。这使得 UnoCSS 的 CSS 小而精，据官网介绍，它无需解析，无需AST，无需扫描。它比Windi CSS或Tailwind CSS JIT快5倍！

从原子化的概念本身出发，我们不难发现，这种做法有一种通病，就是我除了要知道基本的 CSS 之外，还需要知道原子化类库的预定义值，也就是说，我们需要提前知道写哪些 class 是有效的，哪些是无法识别的。

在现代化编辑器中，我们可以使用编辑器扩展来识别这些类名。

比如在 VSCode 中的 UnoCSS 扩展

它可以在 HTML 中提示开发者这个类名下将解析出的 css

也可以进行自动补全。

是的这很方便，但是我们依旧要大概知道这些 预设 class 的写法，对其不熟悉的的用户，可能还要翻阅文档来书写。

我就在想，为什么没有一个原子化库，可以支持智能识别呢，比如我想实现一个行高

按照上图中的预设，我需要依次打出 l、i、n、e、-，才匹配到了第一个和行高有关的属性，如果情况再搞笑一点，我根本不知道 line 怎么写怎么办？

我相信很多同学可能会有共情，因为我们在写传统 CSS 时，一般是打出我们自己熟悉的几个字母，依靠编辑器的自动补全（emmet）来做的，像这样：

嗯，看起来很舒服，只需要打出少量的字母，就可以识别到了。

先看一下传统的字面量 Uno 预设

我们可以自定义一些个人比较熟悉的简写。

或者写一些正则，来支持更复杂的数值插入等

好吧，看到这我都上不来气儿了，这我要写到什么时候去？

确实，一个一个的去自定义规则，花费了非常多的精力和时间，那我们看一下社区有没有提供相对通用的规则呢， UnoCSS社区预设

好吧，可能有，但是太多了，且大多是一些个性化的实现。

于是我准备手动做一个类似 emmet 补全的预设，希望它可以做到识别任意写法，比如：

• line-height1px
• lh24px
• lh1
• lh1rem
• lineh1
• lihei1
• ...等等你习惯的写法

字母+数字

/^[a-zA-Z]+(\d+)$/

字母+数字+单位

/^[a-zA-Z]+(\d+)+(vh|vw|px|rem|em|%)$/

字母+颜色

/^[a-zA-Z-]+(#[a-zA-Z0-9]+)$/

字母+冒号+字母

/^[a-zA-Z]+:+[a-zA-Z]$/

也就是说，我们的 rules 会长这样：

    rules: [

      [

        /^[a-zA-Z]+(\d+)$/,

        ([a, d]) => {

          const [property, unit] = findBestMatch(a, customproperty)

          if (!property) return

          return { [property]: `${d || ''}${unit || ''}` }

        }

      ],

      [

        /^[a-zA-Z]+(\d+)+(vh|vw|px|rem|em|%)$/,

        ([a, d, u]) => {

          const [property] = findBestMatch(a, customproperty)

          if (!property) return

          return { [property]: `${d || ''}${u}` }

        }

      ],

      [

        /^[a-zA-Z-]+(#[a-zA-Z0-9]+)$/,

        ([a, c]) => {

          const [property] = findBestMatch(a, customproperty)

          if (!property) return

          return { [property]: c }

        }

      ],

      [

        /^[a-zA-Z]+:+[a-zA-Z]$/,

        ([a]) => {

          const [property] = findBestMatch(a, customproperty)

          if (!property) return

          const propertyName = property.split(':')[0]

          const propertyValue = property.split(':')[1]

          return { [propertyName]: propertyValue }

        }

      ],

    ]

接下来，只要实现 findBestMatch 方法就好了。

正如刚刚提到的，我们需要模拟一个 emmet 的提示，规则大概是这样的

0. 匹配顺序一致
1. 至少命中 2 字符
2. 可以自定义单位