应合理使用CSS框架而非全盘依赖：适合用框架的场景包括标准化布局、基础交互状态、原子类原型开发及团队规范覆盖度高时；必须手写样式的情况有品牌设计系统、复杂组件行为、语义化结构及性能敏感区域。
不应该把所有样式都交给 CSS 框架。框架是工具，不是替代思考的方案；用得过度会牺牲可维护性、性能和设计一致性。
哪些场景适合直接用 CSS 框架
框架的核心价值在于快速搭建基础结构和通用组件。以下情况可以直接使用：
- 标准化布局（如栅格系统、响应式断点）——Bootstrap 的
.container、Tailwind 的grid-cols-3 md:grid-cols-6 - 基础交互状态（如按钮悬停、禁用、焦点样式）——多数框架已做跨浏览器适配
- 原子类驱动的快速原型（如 Tailwind 的
text-lg font-bold p-4 rounded-lg bg-blue-500）适合内容型页面或内部工具 - 团队已有统一规范且框架能覆盖 80%+ 常用模式时，可降低协作成本
哪些样式必须自己写，不能依赖框架
框架无法也不该代劳业务与品牌相关的视觉逻辑：
- 品牌专属设计系统：主色变体、特殊阴影/圆角规则、图标字体集成、动效节奏（如 loading 微交互动画）
- 复杂组件行为：带拖拽排序的卡片列表、多级下拉菜单、图表容器尺寸自适应逻辑
-
语义化结构样式：文章内
figure/figcaption排版、自定义表单验证提示位置、屏幕阅读器友好的隐藏逻辑 - 性能敏感区域：首屏关键区块（如 hero banner）避免通过框架类叠加多层重绘，应手写精简 CSS
怎么划清“用框架”和“自己写”的界限
一个实用判断标准：看样式是否随业务变化而高频变动。稳定不变的用框架，常改的必须抽离为项目专属类或 CSS-in-JS 变量。
立即学习“前端免费学习笔记（深入）”；
- 把框架当作“基础词汇”，自己定义“业务短语”——比如框架提供
bg-gray-100，你定义.card-surface并在其中复用它，同时加 border 和过渡效果 - 禁止在 HTML 中混用框架类 + 自定义类实现同一功能（例如既用
flex又写display: flex），保持职责清晰 - 用 CSS 自定义属性（
--primary-color）承接品牌变量，框架配置文件（如 Tailwind 的theme.extend.colors）只作映射，不直接写死值
小技巧：渐进式迁移策略
老项目不必全量替换，可分阶段收编：
- 新功能模块默认用框架原子类 + 少量自定义 wrapper 类
- 重构旧模块时，把重复出现的组合类（如
flex items-center p-2 rounded text-sm）提取为语义化类名 - 建立团队《CSS 写法公约》，明确哪些类允许直接用、哪些必须走 design token、哪些禁用（如
!important或float）
基本上就这些。框架省时间，但边界感决定长期体验。写 CSS 不是填空，是做决策。
