组件化是开发者用框架搭建的，非框架自动提供；纯CSS框架仅提供样式工具，组件化需通过HTML+CSS+JS封装可复用、有边界、样式隔离的单元。
组件化不是框架给的，是人用框架搭出来的
纯 CSS 框架（比如 Bootstrap、Tailwind CSS）本身不提供组件化能力——它们只提供样式工具和预设类名。所谓“用框架实现组件化”，本质是你在框架基础上，用 HTML + CSS + JS（或现代前端框架）封装可复用、有边界、能隔离样式的单元。框架只是降低样式冲突和重复劳动的底座，不是自动帮你拆组件的魔法。
Tailwind CSS 怎么配合 React/Vue 做真正组件化
Tailwind 本身无组件概念，但它的原子类 + @apply + CSS-in-JS 或 scoped CSS 的组合，能让组件样式天然收敛。关键不在“用没用 Tailwind”，而在你是否把样式声明约束在组件内部。
- React 中：用
className直接写原子类，避免全局 class；需要复用样式逻辑时，抽成自定义 Hook 或 styled component 封装@apply规则 - Vue 中：务必用
<style scoped>，配合@apply写局部 utility 组合，例如：.btn { @apply py-2 px-4 rounded bg-blue-500 text-white hover:bg-blue-600; } - 别把
tailwind.config.js里加一堆自定义extend.colors当成组件化——那只是主题扩展，跟组件无关 - 警惕 “class 字符串拼接”：像
className={`btn ${isPrimary ? 'bg-blue-500' : 'bg-gray-300'}`}看似灵活，实则破坏可维护性；应封装为<Button variant="primary">这类带语义的组件
Bootstrap 的 class 冲突怎么破——组件化前先做减法
Bootstrap 默认全局注入大量 class（如 .btn、.container），直接套用极易污染其他组件样式。组件化第一步不是封装，而是隔离。
- 用
bootstrap/scss/bootstrap.scss替代完整bootstrap.min.css，按需引入：只@import "mixins"和"utilities"，跳过"components" - 所有组件内使用 Bootstrap，必须走 CSS Modules 或 scoped style，禁止在全局样式表里写
.my-card .btn这类穿透式选择器 - 遇到
.form-control被覆盖？不是改 Bootstrap，而是用:where(.my-form) .form-control提升局部优先级，或直接用class="form-control my-form-input"双重标识 - Bootstrap 5 的
data-bs-*属性是 JS 行为入口，组件化时要主动接管（比如用 React 的useRef控制Modal显示），否则样式和行为会脱节
为什么 CSS-in-JS（如 Emotion）比纯 CSS 框架更接近组件化本质
因为它的样式作用域天然绑定到 JS 模块，无需额外约定或构建配置就能实现“一组件一样式文件”。但代价是运行时开销和 SSR 兼容成本。
立即学习“前端免费学习笔记（深入）”；
-
css函数生成唯一哈希类名，彻底规避命名冲突；cx合并条件 class 更安全，比字符串拼接可靠 - 可直接在组件内写响应式逻辑：
const buttonStyle = css` background: ${props => props.primary ? '#007bff' : '#6c757d'}; @media (max-width: 768px) { padding: 0.5rem; }`; - 不推荐全量迁移旧项目——CSS-in-JS 对设计系统友好，但对已有 Bootstrap 页面做增量改造，反而增加心智负担
- 注意 Emotion 的
Global组件仍会注入全局样式，慎用于 reset 或 font-face，这类内容更适合放在独立base.css中由构建工具处理
组件化的卡点从来不在框架选型，而在样式作用域意识和封装粒度控制。一个 Card 组件该暴露几个 prop？它的阴影、圆角、内边距要不要随主题切换？这些决策比“用不用 Tailwind”重要得多。框架只是让这些决策更容易落地的杠杆，不是替代思考的黑箱。
