用 CSS 框架反而拖慢初期开发，因其引入大量未使用样式、增加构建时间与渲染阻塞，且小项目中定制成本高、调试困难；真正提效需精准配置、精简体积、按需抽离组件。
为什么 用 CSS 框架反而拖慢初期开发？
不是所有项目都适合开箱即用的 CSS 框架。当你只做一页登录表单，却引入 tailwindcss 全量配置或 bootstrap.min.css（超 200KB），实际是用 1000+ 条未使用的规则换来了 3 行样式——构建时间变长、首屏渲染阻塞、DevTools 里满屏 .bg-gray-100 找不到来源。
真实瓶颈常在「定制成本」：想改 .btn-primary 的圆角和阴影，得查文档、翻源码、覆盖变量、清缓存；而手写 button {border-radius: 6px; box-shadow: 0 1px 3px rgba(0,0,0,0.1); } 两秒完事。
- 小项目 / 内部 工具 / A/B 测试页：优先手写原子类或内联关键样式
- 框架真正起效的前提是：团队已约定设计系统边界，且有至少 3 个中等页面需复用布局逻辑
- 警惕
@layer base或!default变量嵌套过深——Tailwind 的theme.extend.spacing和 Bootstrap 的$spacers修改后，常因缓存导致热更新不生效
如何让 CSS 框架真正加速迭代？
关键不在“用不用”，而在“怎么切”。把框架当乐高底板，而非整栋积木房。
以 tailwindcss 为例，真正提效的操作是：
立即学习 “ 前端免费学习笔记（深入）”；
- 关闭默认的
preflight（重置样式），改用@layer base {* { margin: 0;} }精简版，减少 40% 初始 CSS 体积 - 用
content配置精准扫描路径：content: ["./src/**/*.{js,ts,jsx,tsx}"]，避免全盘扫描 node_modules 导致构建变慢 - 将高频组合抽成
@layer components：@layer components {.card { @apply rounded-lg border p-4 bg-white shadow-sm;} }——既保留语义，又规避重复写
class="tuc-78a64be6-caf0e2-0 rounded-lg border p-4 bg-white shadow-sm tuc-78a64be6-caf0e2-0"
Bootstrap 5 的 utility 类 vs 自己写 CSS：性能差在哪？
表面看 class="tuc-78a64be6-caf0e2-0 d-flex justify-content-between align-items-center tuc-78a64be6-caf0e2-0" 比手写 Flex 布局快，但真实代价藏在三处：
- CSS 文件体积：Bootstrap 5 的
utilities.css单文件超 180KB（gzip 后约 32KB），其中 60% 的类（如text-decoration-line-through）你永远用不到 - 浏览器 渲染压力：每个 utility class 都是独立选择器，
.m-0、.m-1、.m-2…… 共生成 200+ 条规则，比[data-spacing="sm"] {margin: 0.25rem;}单条规则更占 Style Sheer 内存 - 调试断点失效：Chrome DevTools 中点击元素，看到的是
.ps-3，但无法直接跳转到对应源码行——因为它是从 Sass 循环生成的，没有真实文件映射
什么时候该放弃框架，回归原生 CSS？
当出现以下任一信号，说明框架已成负资产：
- 为绕过框架的响应式断点，开始写
class="tuc-78a64be6-caf0e2-0 hidden md:block lg:hidden tuc-78a64be6-caf0e2-0"+ 自定义媒体查询，代码比纯 CSS 还难读 -
!important出现频率 > 3 次 / 页面，本质是框架的 specificity 层级压过了你的业务样式 - 设计师给的间距单位是
8px / 12px / 16px，而你正在把theme.spacing从1rem改成4px，并祈祷所有第三方组件不崩 - 执行
npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify耗时超过 800ms，且每次保存都触发全量重建
这时候删掉 tailwind.config.js，建一个 src/styles/base.css，只写 :root {--space-xs: 4px; --space-sm: 8px;}，效率反而回升。
