原子类框架旨在“不写新CSS”，通过预编译类名（如bg-black、pa3）提升开发速度，但易致HTML语义脱钩、维护困难；适用快速原型等场景，不适用于品牌官网等需高视觉灵活性的项目。
原子类框架不是为了“少写代码”，而是为了“不写新CSS”——只要设计系统稳定，tachyons 类名组合就能覆盖 90% 的样式需求，但滥用会导致 HTML 膨胀、可维护性反降。
为什么 bg-black + pa3 比自定义 class 更快，却更容易失控？
原子类本质是预编译的 CSS 规则映射，bg-black 对应 background-color: #000，pa3 对应 padding: 1rem。它省去了写 CSS 文件、起名、作用域管理的步骤，开发时确实快。但问题出在语义脱钩：HTML 里堆满 mt4 mb2 pl2 pr2 flex items-center justify-between，没人能一眼看出这是个导航栏头；重构时也难定位——改一个间距，得全局搜 mb2，而不是搜 .header。
- 适用场景：组件库封装前的快速原型、CMS 输出的富文本样式兜底、设计 token 高度收敛的后台系统
- 不适用场景：面向用户的品牌官网、需频繁视觉迭代的营销页、团队 CSS 工程化已成熟项目
- 关键判断点：你是否愿意用 HTML 层承担部分设计约束？如果设计稿改了圆角尺寸，你是改 JS 逻辑动态切类名，还是接受所有
br2一起变？
hover-bg-near-black 这类复合类名的解析逻辑是什么？
Tachyons 的类名不是随意拼的，有明确前缀规则：hover- 表示伪类，bg- 是 background，near-black 是预设色值（#111）。组合后生成的 CSS 是 .hover-bg-near-black:hover { background-color: #111 }。它不支持任意嵌套，比如 hover-focus-bg-red 不存在，也不生成 :focus:hover 这种双伪类选择器。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 所有伪类前缀只支持单层：
hover-、focus-、active-、disabled- - 响应式前缀如
md-、lg-必须放在最前，例如md-flex lg-text-center，顺序错（如flex-md）就无效 - 注意冲突：同时写
bg-white和hover-bg-black，悬停时背景会变黑，但没写默认态文字色，可能遇到黑底黑字
如何避免 HTML 变成“类名字符串拼接器”？
当一个按钮需要 8 个原子类：fw6 no-underline white bg-blue hover-bg-light-blue pa3 br2 inline-flex items-center，说明已经越过原子类的舒适区。这时候该做的是提取“意图”，而非继续堆砌。
立即学习“前端免费学习笔记（深入）”；
- 用
data-*属性标记语义，比如data-button="primary"，再用少量 CSS 覆盖关键组合（不破坏原子类基础） - 在构建流程中用 PostCSS 插件合并高频组合，把
fw6 pa3 br2自动聚合成btn-base，仅用于复用率 >5 次的模式 - 禁止在模板中写带逻辑的类名拼接，例如
class="{{ if active }}bg-blue{{ else }}bg-gray{{ end }}"—— 改用class="{{ buttonClass }}"，把组合逻辑收口到 JS 或工具函数里
真正难的不是学会 dn（display: none）或 truncate，而是判断什么时候该停手、抽离、妥协。Tachyons 的 CSS 文件只有 14KB gzipped，但团队若每天花 20 分钟争论“这个边距该用 ml3 还是 pl4”，那节省的编译时间早就赔进去了。
