内联类并非更高效，而是将效率问题从命名与文件协调转向组合与封装决策；它省去css文件编写和bem命名纠结，但未减轻设计系统抽象责任。
内联类不是“更高效”的代名词，而是把效率问题从命名和文件协调转移到了组合与封装决策上——它省掉了命名纠结和文件跳转，但没省掉设计系统抽象的责任。
内联类直接跳过CSS文件编写和命名环节
传统BEM流程里，写一个按钮要先想名字（btn还是primary-button），再建文件（button.css），再定义选择器（.btn__text），最后回HTML里引用。Tailwind直接在HTML里写class="px-4 py-2 bg-blue-500 text-white rounded hover:bg-blue-600"，所有视觉信息一目了然，无需上下文切换。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 不用维护单独的CSS文件，也不用担心
.header__title--large被误删或重名覆盖 - 响应式前缀（如
sm:text-sm）和状态伪类（如hover:underline）天然支持，不依赖额外JS或Sass嵌套 - 工具链（如VS Code插件、Emmet）能自动补全类名，而BEM类名无法被可靠提示
BEM命名带来的协作成本在Tailwind中被转移而非消失
你不再为card__body--compact要不要加--纠结，但得决定p-3和p-4哪个才符合设计规范。Tailwind没消除语义抽象，只是把它推给了团队级约定。
- 颜色值（
text-red-500）不等于业务语义，“错误提示文字”仍需统一成text-error这样的别名（通过theme.extend.colors或@layer components） - 间距单位（
space-y-4）不等于设计语言，“卡片内边距”必须由Design System明确定义，否则不同人会各自选p-4、p-5、py-3 px-6 - 没有
button--disabled这种状态类，但JS逻辑里得显式控制opacity-70 cursor-not-allowed组合，漏掉一个就破坏一致性
混用BEM和Tailwind时最常踩的坑是责任错位
不是语法冲突，而是不知道谁该管什么。比如给<div class="card__header p-4 bg-white">加<code>md:flex，看起来没问题，但一旦card__header在其他地方被JS用来做DOM查询，而样式又依赖md:flex，那这个查询就隐含了响应式条件——可JS代码里根本看不到。
- BEM类（如
card__header）应只用于结构定位、测试选择器、组件边界标识，不参与视觉渲染 - Tailwind类（如
p-4、bg-white）只负责视觉表现，不能承载“这是标题区域”的语义 - 禁止在BEM类名里塞Tailwind语义，例如
card__header-text-sm是反模式；text-sm该直接写在HTML里 - 如果用了
important: false，BEM的CSS规则（如.card__header { padding: 1rem; }）可能被Tailwind的p-4覆盖且无报错
真正难的从来不是写flex-col gap-2，而是让整个团队对gap-2代表什么达成共识，并在Figma标注、PRD文档、自动化测试里保持一致。Tailwind把命名压力卸载了，但把抽象责任放大了。
