直接写CSS易致样式不一致，因命名、重置、单位等无统一规范；CSS框架通过集中定义变量与约束消费实现一致性，Tailwind适合精细控制，Bootstrap适合快速原型，自建原子类适配现有SCSS架构；老页面应双轨并行、渐进替换，并注意作用域、构建配置及团队协作规范。
为什么直接写 CSS 容易导致多页面样式不一致
不同开发者对同一组件（比如 .btn）的命名、层级、重置方式理解不同，加上没有强制约束，margin 写成 10px 还是 1rem、是否加 box-sizing: border-box 全凭习惯。更麻烦的是，页面间复用样式时经常复制粘贴，一处改了另一处漏改，!important 越堆越多，最终变成“谁敢动这个 class 就崩一个页面”。
用 CSS 框架不是为了套模板，而是把样式决策收口：颜色、间距、字体大小、响应式断点这些基础变量只定义一次，所有页面引用同一套源文件，改 $primary-color 就全局生效。
怎么选框架：Tailwind vs Bootstrap vs 自建原子类
别被“框架”二字吓住——核心是“集中定义 + 一致消费”，不一定要用整套 UI 组件：
-
Tailwind：适合已有设计系统、需要精细控制的项目。所有样式来自预设的 utility class（如
text-lg、bg-blue-500），通过tailwind.config.js统一配色和尺寸，编译后只打包用到的类，体积可控 -
Bootstrap：适合快速出原型或团队前端经验参差不齐的情况。它的
reboot.css做了基础重置，variables.scss允许覆盖默认值，但要注意避免直接写class="btn btn-primary"后又在局部加style="color: red"，破坏统一性 -
自建原子类：如果项目已有 SCSS 架构，可以提取
_spacing.scss（定义$space-xs: 4px）、_colors.scss（定义$color-text: #333），再封装@mixin pad-y($size)，比直接写padding: 8px 0更易维护
如何让老页面平滑接入新样式体系
强行全量替换会阻塞上线，推荐“双轨并行 + 渐进替换”：
- 新建页面一律使用新框架的 class，老页面不动，但禁止新增内联样式或
style标签 - 给老页面加一层 wrapper class（如
legacy-page），在新 CSS 文件里用.legacy-page .btn { ... }单独兼容，避免污染全局 - 用 PostCSS 插件
postcss-custom-properties把旧 CSS 中的硬编码值（如color: #007bff）替换成color: var(--primary)，再对接新变量表 - 上线前跑一遍
npx stylelint --fix，自动修正不符合新规范的写法（比如禁止使用float、强制用flex替代）
容易被忽略的坑：CSS 作用域与构建流程
即使用了框架，以下问题仍会导致样式“看似统一、实则混乱”：
立即学习“前端免费学习笔记（深入）”；
- 多个入口文件各自
@import同一套变量，但 Webpack 没配置css-loader的modules: false，导致变量作用域隔离，$space-md在 pageA.scss 和 pageB.scss 里其实是两个副本 - 开发时用
@import 'tailwindcss/base'，但生产环境忘了在postcss.config.js里加tailwindcss()插件，结果所有 utility class 都没生成 - 团队成员本地没装
prettier-plugin-tailwindcss，写出来的 class 顺序五花八门（flex p-2 text-red bg-whitevsbg-white text-red flex p-2），影响 diff 可读性
@layer base {
* {
box-sizing: border-box;
}
body {
margin: 0;
line-height: 1.5;
font-family: system-ui, -apple-system, sans-serif;
}
}
@layer components {
.card {
@apply bg-white rounded-lg shadow-sm p-4;
}
}真正难的不是引入框架，而是让所有人遵守同一套“样式语法”。变量名要不要带单位（$space-4: 1rem 还是 $space-4: 4）、utility class 是否允许嵌套（md:text-xl）、响应式断点怎么命名（sm/md 还是 tablet/desktop）——这些细节定不下来，框架就只是个好看的壳。
