Tachyons 类名看似反直觉实则规律统一：前缀（m/p/t/b/l/r/x/y）+数值/值类型，严格按文档穷举，顺序错或拼写错即失效；需禁用内联样式、避免自定义类、按需构建CSS，并理解其无JIT、无动态类、固定比例等本质约束。
为什么 tachyons 的类名看起来反直觉但实际不难上手
它不是靠语义命名（比如 .card 或 .header-nav），而是用原子化函数名表达样式行为，比如 pa2 是 padding-all 2 级（0.5rem），bg-blue 是 background-color: blue。初看像密码，但规律很固定：前缀 + 数值/值类型，且所有组合都在文档里穷举过。
常见错误是试图“猜”类名，比如写 pt3 却忘了 t 代表 top —— 实际上 pt3 是对的，但有人误写成 padding-t3 或 padt3，这些根本不会生效。
-
ma0、mt3、mb4这类缩写必须严格按官方前缀表来，m=margin，p=padding，t=top，b=bottom，l=left，r=right，x=horizontal，y=vertical - 数值级数默认是 0–7，对应 0, .25rem, .5rem, .75rem, 1rem, 1.25rem, 1.5rem, 2rem；想改就得重编译 CSS 或用自定义构建
- 响应式写法是加前缀，比如
sm-pa2表示在 small 断点及以上才生效，不是pa2-sm—— 顺序错就失效
如何避免 tachyons 在真实项目中变成“类名爆炸”
它本身不约束组合方式，一个元素写七八个类很常见，比如 pa3 bg-white br2 shadow-1 flex items-center justify-between。问题不在多，而在失控：没人知道哪些类该复用、哪些该删、哪些已废弃。
典型场景是团队协作时，A 写了 f6 black-80（小号深灰字），B 后来加了个 dark-gray，结果两个颜色系统并存；或者直接内联 style 覆盖，让 tachyons 失去意义。
立即学习“前端免费学习笔记（深入）”；
- 禁用直接写
style属性，所有视觉调整必须走类名；否则调试时永远分不清是哪层样式在起作用 - 不要自己造新类（如
.btn-primary），真需要封装就用 CSS-in-JS 或预处理器 extends，但别混进 HTML - 用
npm run build:css（如果用了定制构建）确保只打包项目实际用到的类，避免全量 200KB+ 的tachyons.min.css拖慢首屏
tachyons 和 Tailwind 的关键差异在哪，什么时候不该换
两者都是功能类，但 tachyons 更“死板”：没有 JIT 编译，没有 @apply，不支持任意值（比如不能写 ml-[17px]），也不带插件生态。它适合小到中型静态站点、邮件模板、或作为设计系统底层工具链的一部分。
错误判断是“既然 Tailwind 更火，那现在学 tachyons 就是倒退”。其实很多老项目还在用，而且它的 CSS 文件极小（gzip 后约 14KB）、零运行时、兼容 IE9+，这些在嵌入式管理后台或邮件渲染中仍是硬需求。
- 如果你需要动态生成类名（比如
class={`${size}-font`}），tachyons不支持运行时拼接 —— 它的类必须静态存在 CSS 中 - 没有
hover:、focus:等伪类变体，要用就得手动写:hover规则或搭配tachyons-css的扩展包 - 字体大小、行高、间距等比例是固定 scale，不能像 Tailwind 那样在
tailwind.config.js里自由调，改就得 fork 源码或重写变量
本地开发时怎么快速验证某个类名是否有效
别打开文档查，也别靠记忆。最稳的方式是用浏览器开发者工具实时试：选中元素 → 在 class 输入框里直接敲，比如输入 bg-green，看背景是否变绿；输错（如 bg-greeen）就毫无反应，说明没这个类。
容易被忽略的是：某些类名依赖其他类才能生效。比如 flex 必须和 items-center 搭配才有垂直居中效果，单独加 items-center 对非 flex 容器无效 —— 这不是 bug，是 CSS 本身的限制。
- 检查是否漏了基础布局类，比如
flex、grid、relative，否则absolute、justify-between这些会静默失效 - 注意层级顺序：多个
z-类同时存在时，后写的会覆盖先写的（CSS cascade 规则），不是按数字大小自动排序 - 用
npm install tachyons --save-dev后，别直接引用 CDN，本地引入能配合 source map 查到具体哪行 CSS 定义了pa3
