项目规模决定CSS工具选型：小项目用原生CSS+PostCSS；中项目用UnoCSS/Windi CSS+CSS Modules+设计Token；大项目需Design Token体系+CSS-in-JS/构建时提取+容器查询/@layer。
项目规模决定CSS工具选型逻辑，不是越新越强越好，而是匹配团队能力、迭代节奏和维护成本。
小项目（单页/营销页/内部工具）：手写CSS + 简单工具链
代码量少、需求稳定、上线快，过度工程化反而拖慢进度。
- 用原生CSS + CSS自定义属性管理颜色、间距等基础变量
- 加一个轻量构建工具（如PostCSS + autoprefixer），解决兼容性问题
- 避免引入Tailwind或Bootstrap这类完整框架——写10行样式却要加载几十KB的工具类，得不偿失
- 可搭配CSS-in-JS库（如goober）做局部组
件样式隔离，不污染全局
件样式隔离，不污染全局中型项目（多页应用/中后台系统）：原子化方案 + 基础设计系统
需要一定复用性、主题切换能力，同时保持开发效率和可维护性。
- 推荐UnoCSS或Windi CSS：按需生成工具类，体积可控，写法接近Tailwind但更灵活
- 用CSS Modules或Vue Scoped Style保障组件样式作用域
- 抽离基础设计Token（字号、圆角、阴影等）到独立JSON或JS模块，供样式和JS逻辑共用
- 避免直接用Bootstrap或Ant Design的全套CSS——定制成本高，容易被样式权重*
大型项目（多团队协作/长期演进产品）：设计系统驱动 + 构建时CSS提取
样式一致性、跨端适配、主题管理、性能监控都成为刚需。
- 建立团队级Design Token体系，用Style Dictionary或Theo生成多平台输出（CSS、JS、Android、iOS）
- 采用CSS-in-JS（如Linaria）或构建时提取CSS（如Astro + Windi），实现动态主题与静态优化兼顾
- 关键页面启用CSS容器查询和层叠层（@layer）组织样式优先级，降低维护熵值
- 禁用全局CSS重置（如Normalize.css全量引入），改用按需patch方式修复特定浏览器问题
通用避坑提醒
别让工具反向定义开发流程。以下信号说明选型可能出问题：
- 为支持一个动画效果，引入整个动画库并修改构建配置
- 团队一半时间在调试CSS优先级，而不是实现业务逻辑
- 换主题要改三处配置、清两次缓存、重启两次服务
- 新人入职三天还搞不清按钮样式到底来自哪一层
工具是杠杆，不是目的。先理清项目生命周期里谁写样式、谁改主题、谁压测性能、谁接手维护，再反推该用什么。
