组件化是开发者用框架搭建的，非框架自动提供；纯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 中：务必用 ，配合 @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'}`} 看似灵活，实则破坏可维护性；应封装为 这类带语义的组件

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”重要得多。框架只是让这些决策更容易落地的杠杆，不是替代思考的黑箱。