应先定义核心变量并配置框架主题，禁用冗余模块、封装原子类组件，用postcss+css变量建立规范层，从按钮切入渐进统一，最小闭环验证变量一致性。
为什么直接套用 Bootstrap 或 Tailwind 会出问题
项目没有设计规范时，直接引入 Bootstrap 或 Tailwind CSS 容易导致视觉割裂：组件样式和业务 UI 风格不匹配，比如 btn-primary 的蓝色饱和度太高，或 .card 的阴影太重。更麻烦的是，团队成员会各自覆盖默认样式，最后变成“框架 + 一堆 !important”的混合体。
关键不是选哪个框架，而是用框架当“约束工具”，而不是“填充模板”。
- 先定义 3–5 个核心变量（如主色、圆角尺寸、基础间距），再配置框架主题，而非接受默认值
- 禁用框架中不用的模块（如 Bootstrap 的
carousel、tooltip），通过@import按需加载 - 所有业务组件必须基于框架原子类封装，禁止在 JSX/HTML 中直接写
style="margin-left: 16px"
如何用 PostCSS + cssnext 快速建立可维护的规范层
不需要从零写设计系统，用 postcss-preset-env 和 postcss-custom-properties 把 CSS 变量变成事实标准，比 SCSS 变量更易被 JS 读取、也更利于后续接入 Design Token 工具。
在 src/styles/vars.css 中集中声明：
立即学习“前端免费学习笔记（深入）”；
:root {
--color-brand: #4a6fa5;
--color-text-primary: #2d3748;
--space-unit: 4px;
--radius-sm: calc(var(--space-unit) * 2);
--radius-lg: calc(var(--space-unit) * 4);
}然后在组件中只允许使用这些变量：
.button {
padding: calc(var(--space-unit) * 3) calc(var(--space-unit) * 5);
border-radius: var(--radius-sm);
background-color: var(--color-brand);
}- 禁止在组件样式里重复写死像素值（如
12px），一律换算为calc(var(--space-unit) * 3) - CI 流程中加入
grep -r "px" src/styles/ | grep -v "vars.css"做校验 - JS 侧可通过
getComputedStyle(document.documentElement).getPropertyValue('--color-brand')获取，方便做主题切换
已有项目怎么渐进式统一？从按钮开始切口
按钮是高频、高可见、样式差异最明显的组件。不要一上来改全部，而是锁定 Button 组件作为规范落地的第一站。
步骤如下：
- 全局搜索所有
class="btn"、class="primary-btn"等自定义按钮类名，统计出现频次和样式特征 - 新建
src/components/Button/Button.module.css，只暴露button、button--small、button--outline三类基础变体 - 用
CSS Custom Properties控制颜色/尺寸，避免写死值；所有变体都继承同一套padding和border-radius计算逻辑 - 上线后，在 ESLint 中加规则：禁止在 JSX 中使用
className包含btn-或primary字样（用no-restricted-syntax）
设计师不参与、开发又没时间定规范，怎么办
这时候别等“完整规范”，先用最小闭环跑起来：挑一个页面（比如登录页），让 1–2 名前端和 1 名产品一起花半天时间，把里面所有颜色、字号、边距、圆角手动提取成变量，写进 vars.css，然后重写该页面的样式，确保它看起来“比原来更一致”。这个页面就成了活的规范示例。
后续新增页面必须对齐这个登录页的变量使用方式，而不是对齐“感觉”。一致性不是靠人记住，是靠构建时检查、运行时读取、代码里强制引用。
真正难的不是写多少 CSS，是让每个人每次写样式时，第一反应是“我该用哪个变量”，而不是“我该怎么调这个颜色”。
