17370845950

CSS选型应坚持“够用、可控、可维护”原则：小项目用原生CSS，中大型项目再引入Sass或Tailwind；重调试友好性、source map、渐进迁移与设计令牌统一；团队需规范命名、体积监控和lint规则。

用CSS工具和框架，核心是“够用、可控、可维护”，不是堆功能或追新。选得不合适，反而拖慢开发、增加bug、让团队协作变难。

明确项目规模与长期维护需求

小项目或临时页面，直接写原生CSS更轻快；中大型项目才值得引入预处理器（如Sass）或框架（如Tailwind）。别为5页静态站配一套PostCSS+PurgeCSS+自定义设计系统——配置成本远超收益。

• 团队新人多？优先选语法直观、文档好、调试友好的方案（比如Sass比Less生态更稳，Tailwind比Bootstrap更易约束样式边界）
• 要长期迭代？确保工具支持source map、变量提取、主题切换等基础能力
• 已有遗留代码？先评估迁移成本，避免“重写式升级”——可逐步用@use导入Sass模块，或用utility-first方式渐进替换旧class

控制定制深度，避免过度封装

框架自带的按钮、卡片组件很省事，但一旦开始大量覆盖!important、深挖嵌套选择器、或写一堆“my-btn-v2-primary-large-disabled”类名，就等于自己造了一套难懂的方言。

• 用Tailwind？靠配置theme和plugins扩展，而不是写大量@layer components
• 用Bootstrap？删掉不用的SCSS模块（如carousel、tooltip），用bootstrap/scss/functions单独引入所需函数
• 自研UI库？把颜色、间距、圆角等基础值抽成设计令牌（design tokens），CSS变量或JS对象双端同步，别散落在几十个文件里

构建流程要透明，调试不能变黑盒

加了PostCSS插件、CSS-in-JS、原子化生成器之后，浏览器开发者工具里看到的class名可能和源码完全对不上，定位样式来源变困难。

• 开启source map并确保它真正生效（检查Network面板里的.css.map是否返回200）
• Tailwind用户：启用debugScreens或content路径配置准确，避免purge误删关键class
• 避免在构建后手动修改生成的CSS——所有样式变更必须可追溯到源文件

团队规范比工具本身更重要

再好的框架，如果没人统一命名、没人清理废弃class、没人review CSS体积增长，半年后照样变成样式泥潭。

• 约定BEM或类似命名法，哪怕用Tailwind也规定何时用，何时抽成.my-card-wrapper
• 把CSS体积监控接入CI（比如用size-limit检测单个组件CSS是否暴涨）
• 定期跑stylelint，规则聚焦在可读性上：no-duplicate-selectors、max-nesting-depth、selector-class-pattern

基本上就这些。工具是拐杖，不是腿。用得舒服的前提，是清楚自己想往哪儿走，以及谁会接着走这条路。