tailwind css更受欢迎的根本原因是它将样式决策锚定在html中，实现免文件切换、自动清理冗余样式、响应式前缀化、变体共存及jit按需编译。
Tailwind CSS 比传统 CSS 开发模式更受欢迎，根本原因不是“它更好”，而是它把样式决策从抽象的类名设计、文件跳转和全局冲突中解放出来，直接锚定在 HTML 结构里——改样式不用切文件，删组件自动清样式，加响应式只多一个前缀。
class 名不再需要“想名字”
传统 CSS 里写 .sidebar-inner-wrapper 或 .btn-primary-sm 这类类名，本质是在做语义抽象，但项目一久，没人记得这个“sm”到底指 padding 还是 font-size；Tailwind 直接用 px-3 py-1.5 text-sm rounded，每个类都对应一个确定的声明，不靠命名猜意图，也不怕重名覆盖。
- 常见错误现象：团队新人给按钮加
class="primary-btn"，结果发现三个地方都用了，但圆角/阴影/禁用态逻辑各不相同，最后只能靠!important补救 - Tailwind 解法：每个按钮样式写死在标签上，
bg-indigo-600 hover:bg-indigo-700 disabled:opacity-50全部可见、可复制、不可复用错 - 性能影响：没有抽象层，就不存在“为复用而抽象”带来的冗余类或未删尽的旧样式；PurgeCSS / JIT 编译后体积天然小
响应式开发不再手写媒体查询
传统方式要反复写 @media (min-width: 768px) { ... } 块，嵌套深了还容易漏断点；Tailwind 把断点前缀固化为 sm:、md:、lg:，且能叠加在任意工具类上。
- 使用场景：一个卡片标题在手机居中、平板左对齐、桌面右对齐，只需
text-center sm:text-left lg:text-right - 参数差异：Tailwind 默认断点值（
640px、768px、1024px）可改，但绝大多数项目直接用默认值就够用；Bootstrap 的d-none d-md-block只控制显隐，没法组合hover或focus - 容易踩的坑：把
md:text-lg写成text-md（Tailwind 没这写法），或漏掉content配置导致断点类不生成
样式生命周期随 HTML 组件一起管理
传统 CSS 文件越积越大，删一个页面常得手动翻找并清理对应样式；Tailwind 的样式绑定在 HTML 标签上，HTML 删了，对应类自然失效，JIT 模式下连打包都不会包含。
- 常见错误现象：迁移旧项目时，
src/pages/Home.js已删，但styles/home.css还留在仓库里，且被其他组件意外 import - Tailwind 解法：只要
content字段正确扫描到所有模板路径（比如./src/**/*.{js,ts,jsx,tsx}），生产构建就只打包真实用到的类 - 兼容性影响：JIT 模式开启后，
top-[-113px]、bg-[#165DFF]这类任意值语法才生效；传统 CSS 或 Bootstrap 完全不支持，只能退回到 inline style 或额外 SCSS 变量
暗黑模式、主题切换不再靠 JS 控制 class
传统方案常靠 JS 切 dark-mode 类，再写一堆 .dark .btn 规则；Tailwind 把 dark: 变体编译成标准伪类，且与 hover、focus 等共存无冲突。
- 实操建议：在
tailwind.config.js中启用darkMode: 'class'，然后在上动态加class="dark"；之后直接写dark:bg-gray-800 dark:text-gray-200 - 容易踩的坑：忘了在
content里包含 HTML 模板路径，导致dark:类没生成；或误用prefers-color-scheme模式，导致 SSR 下闪烁 - 为什么这样做：
dark:是 JIT 编译期识别的变体，不是运行时 JS 逻辑，所以零额外 bundle 体积、无 hydration 问题
真正难的不是学 Tailwind 的类名，而是放弃“写一个通用按钮组件”的执念——它不提供组件，只提供零件；你得自己决定哪几个类该复用，什么时候该抽 @apply，以及如何让设计系统约束落在配置而非人力 review 上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
