预处理器适合复用逻辑、分模块管理且团队熟悉嵌套语法的场景；原子化CSS适合UI变动频繁但结构简单的内容型站点；CSS-in-JS适合需作用域隔离与动态样式的组件库或高度交互组件。
预处理器（Sass/Less）适合什么场景
当你需要复用逻辑、分模块管理样式，且团队熟悉嵌套语法和变量机制时，Sass 或 Less 是稳妥选择。它不改变 CSS 本质，只是加了一层编译时的组织能力。
常见错误现象：@import 滥用导致重复编译、全局变量污染、& 嵌套过深引发选择器权重失控；开发时热更新慢，尤其在大项目中 sass --watch 容易卡住。
使用场景：
- 已有成熟 CSS 架构（如 BEM），只需增强可维护性
- 设计系统需统一颜色/断点/动画时长等基础变量
- 构建流程已稳定，能接受额外编译步骤
参数差异：Sass 的 @use 比 @import 更安全，但旧项目迁移成本高；Less 默认允许变量覆盖，Sass 则需显式用 !default，这点容易漏掉导致主题切换失败。
立即学习“前端免费学习笔记（深入）”；
原子化 CSS（Tailwind/Pico/CSS Utility）为什么容易误用
它不是“写得快就一定好”，而是把样式决策从写 CSS 转移到写 HTML，代价是 HTML 变臃肿、语义弱化、响应式类名堆砌难维护。
常见错误现象：class="p-4 bg-blue-500 text-white rounded-lg md:p-6 lg:bg-blue-600" 这类长串类名反复出现，却没抽成组件；自定义 theme.extend.spacing 后未同步更新文档，导致设计师和前端理解错位。
使用场景：
- 内容型站点或营销页，UI 变动频繁但结构简单
- 团队无专职 CSS 工程师，希望降低样式学习成本
- 已用 React/Vue 等组件化框架，样式边界清晰
性能影响：Tailwind 的 purge（现为 content）配置若漏掉动态类名（如 className={isSuccess ? 'text-green-500' : 'text-red-500'}），会导致上线后样式丢失——这是最常被忽略的构建陷阱。
CSS-in-JS（Emotion/Styled-components）该不该进项目
它解决的是“作用域隔离”和“动态样式”两个刚需，但引入运行时开销和 SSR 配置复杂度，不是所有项目都需要。
常见错误现象：css 模板字符串里写大量媒体查询，导致 JS 包体积上涨；服务端渲染时未正确提取关键 CSS，首屏闪动或布局偏移（CLS）升高；用 keyframes 动画但没配 ssr: true，动画失效。
使用场景：
- 组件库开发，需确保样式不泄漏
- 高度交互组件（如拖拽面板、实时图表）依赖 props 计算样式
- 已用 Webpack/Vite，能接受插件链（如
@emotion/babel-plugin）
兼容性影响：Emotion 支持 :hover 等伪类，但某些低版本 Next.js 的 getServerSideProps 中无法注入 Global 样式，必须改用 createGlobalStyle + hydrate 手动触发。
怎么判断该选哪种，而不是听别人说“现在都用 Tailwind”
看你的 CSS 最常在哪出问题：是命名冲突？是响应式调试耗时？是主题切换改 20 个文件？还是上线后某块样式突然不生效？每种架构只解决一部分问题，没有银弹。
真正容易被忽略的点：团队当前的调试习惯。比如设计师用 Chrome DevTools 直接改 .header 查效果，你却用了原子化，那她得在 HTML 里翻半天 flex-col 和 items-start；又比如后端同学偶尔修个按钮颜色，他不会装 Node、跑 npx tailwindcss -i ./src/input.css -o ./dist/output.css，但能直接改 button.css。
架构不是选最潮的，是选让日常修改阻力最小的那个。
