应选CSS-in-JS（如styled-components）当样式强依赖组件状态、props或主题（如暗色模式），适合中大型React项目及设计系统成熟场景，但会增加首屏JS体积、SSR需额外配置且调试类名哈希化。
什么时候该选 CSS-in-JS（比如 styled-components）
当你需要样式强依赖组件状态、主题或 props 时，styled-components 或 @emotion/react 是更自然的选择。比如按钮颜色随 disabled、variant 动态变化，或者整个组件要响应暗色模式切换——这些逻辑写在 JS 里比靠一堆原子类拼凑更直接。
但要注意：它默认生成运行时 CSS，会增加首屏 JS 体积；服务端渲染（SSR）需额外配置 extractCritical 或 cache，否则样式可能闪动；调试时类名是哈希值（如 css-1a2b3c），不便于快速定位。
- 适合中大型 React 项目，尤其是设计系统已沉淀、主题变体多的场景
- 不适合纯静态站点或对首屏性能极其敏感的营销页
- Vue 用户慎用：官方推荐方案是
<style scoped></style>+defineProps响应式绑定，styled-components在 Vue 生态支持弱、社区维护少
什么时候该选原子化 CSS（比如 Tailwind）
当你追求开发速度、团队协作效率，且 UI 风格相对稳定、不频繁突破设计规范时，Tailwind CSS 这类原子化方案见效最快。它把 margin、padding、text-color 全部拆成工具类，写 HTML 就等于写样式，不用切文件、不用起类名、不纠结作用域。
但它的代价是 HTML 变“胖”——一个卡片可能带十多个 class；定制门槛也不低：改圆角统一值不是改一个变量，而是重定义 border-radius 的 token 映射表；而且它默认不处理组件封装，Button 这种可复用单元仍得靠 @apply 或自定义指令来收口，否则容易散落各处。
立即学习“前端免费学习笔记（深入）”；
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 适合业务迭代快、UI 较规范、设计师提供明确设计令牌（design tokens）的团队
- 不适合需要大量自由布局（如复杂动画、非栅格排版）或已有厚重 Sass 架构的老项目强行迁移
- 务必配
tailwind.config.js中的content字段，否则 PurgeCSS 会误删用到的类
CSS-in-JS 和原子化 CSS 都绕不开的兼容性现实
两者都依赖构建时处理：CSS-in-JS 要插件注入样式规则，原子化 CSS 要 PostCSS 解析和 Purge；它们都不兼容 IE11，且在无构建环境（比如直接 <script src></script> 引入）下无法使用。
更关键的是，它们都放弃原生 CSS 的部分能力：@keyframes 在原子化中得靠插件扩展；CSS-in-JS 对伪元素、媒体查询嵌套的支持因库而异，styled-components 支持完整 CSS 语法，但 Emotion 的 css prop 默认不解析 @layer。
- 如果项目必须支持 IE11，老老实实用 Sass + BEM，别硬上
- 如果要用 CSS 变量做主题，原子化 CSS 得手动映射到
theme.colors.primary，而 CSS-in-JS 可直接在模板字面量里调用props.theme.primary - 二者都难以调试“为什么这个 margin 没生效”——因为最终生效的样式来自 JS 注入或构建后产物，不是原始源码
真正卡住落地的，往往不是技术选型，而是团队习惯
原子化 CSS 要求开发者接受“HTML 写样式”的范式转移，而不是“先写结构再补样式”；CSS-in-JS 则要求 JS 工程师对 CSSOM 有基本理解，不然容易写出高权重内联样式覆盖掉全局 reset。
最常被忽略的一点是：无论选哪边，都得配套约束。Tailwind 不加 eslint-plugin-tailwindcss，很快就会冒出 mt-4 ml-2 mr-2 mb-4 这种等价于 m-4 的冗余写法；CSS-in-JS 不配 eslint-plugin-styled-components，就容易出现字符串拼接样式、动态 key 导致重复插入规则等问题。
没有银弹。能跑通的方案，一定是让团队最不痛苦地写出可维护样式，而不是技术文档里最炫的那个。
