选对CSS工具和框架应以提升团队协作效率为核心。需统一规范（如BEM+stylelint或Tailwind）、作用域隔离（CSS Modules/Scoped CSS）、可维护性优先（避免深层嵌套、配source map、重文档），并渐进集成、保留退出路径。
选对CSS工具和框架，不是看谁最火，而是看它能不能让团队写得快、改得稳、查得清、上线少出错。
统一规范：从命名到结构，减少“谁写的谁懂”
团队协作最大的隐形成本，是样式冲突和理解偏差。比如A写了 .btn-primary，B又建了个 .primary-btn，表面功能一样，实际维护时得两边改。用带约定的工具（如BEM命名 + PostCSS插件自动校验），或框架（如Tailwind的utility-first规则），能天然约束写法。
- 推荐搭配：PostCSS + stylelint（可配置BEM/SMACSS规则）
- 小团队可直接用Tailwind，它的类名即语义，无需额外文档解释
- 避免纯手写CSS + 自定义命名，除非有专人做样式治理
按需加载与作用域隔离：别让一个人的改动影响整站
全局样式表一旦膨胀，改一个按钮边距可能让侧边栏错位。现代方案核心是“限制影响范围”：
- CSS Modules：每个组件的样式默认局部作用，Webpack/Vite原生支持
- Scoped CSS（Vue）或 css prop（React + Emotion）：样式绑定到组件，编译后自动加哈希
- 慎用全局重置（如normalize.css）+ 全局变量，建议封装成设计系统基础层，由前端架构师统一维护
可维护性优先：别为炫技牺牲调试效率
团队里总有新成员、临时支援者、甚至后端偶尔改个样式。他们打开开发者工具，需要3秒看懂这个灰色背景来自哪、能否安全删。
立即学习“前端免费学习笔记（深入）”；
- 避免深层嵌套（如Sass里 &__item &__item--active &__item--active:hover），编译后选择器过长，也难定位
- 用source map确保浏览器能精准跳转到源文件（Vite/Webpack默认开，但自定义构建链路要检查）
- 文档比代码更重要：哪怕只是README里一句话——“按钮状态全在
components/Button.css，hover/focus/disabled已预设”
渐进集成：不强求一步到位，但要有退出路径
老项目引入新框架常卡在“要不要重写”。更务实的做法是：
- 新模块用CSS Modules或Tailwind，旧模块不动，通过class组合桥接
- 用PostCSS插件（如postcss-import）把零散CSS按需拼装，避免单文件爆炸
- 所有工具链必须有明确的“降级方案”：比如Tailwind配
@layer base兜底全局样式，万一某天要切走，删掉插件仍能跑
基本上就这些。工具不是越多越好，而是让三个人协作时，像一个人在写；十个人协作时，像三个人在写。
