CSS框架本身不是性能瓶颈，真正拖慢渲染的是深层嵌套结构和隐式触发重排的样式组合；优化重点在于约束嵌套层级≤3、禁用transition:all、对高频元素显式启用合成层，并关闭box-sizing全局设置等高开销特性。
直接说结论：CSS框架本身不是性能瓶颈，真正拖慢渲染的是你用它写出来的深层嵌套结构和隐式触发重排的样式组合。优化重点不在换框架，而在约束写法、隔离动画层、砍掉冗余匹配。
为什么 CSS 框架会让嵌套变深、重绘变多
CSS 框架（比如 Bootstrap、Tailwind 的 utility class 组合）容易诱导开发者写出类似 .container .row .col-6 .card .card-body .btn 这样的选择器链——哪怕实际只用了 class，但 DOM 结构层层包裹后，浏览器仍要为每个元素做完整样式匹配。更麻烦的是，框架默认样式常含 margin、padding、display 等布局属性，一旦 JS 动态增删 class 或修改尺寸，极易触发 layout thrashing。
- 框架提供的响应式类（如
md:flex、lg:grid-cols-3）在媒体查询切换时，可能批量修改display，引发整块区域重排 - 很多框架默认给
button、a加transition: all 0.2s，hover 时只要改了任意属性（比如color+background），就可能连带触发重绘 - Tailwind 的
@layer utilities若叠加过多自定义hover:、focus:变体，会生成大量高 specificity 选择器，加剧 CSSOM 构建耗时
怎么用好框架又不卡顿：三个硬约束
别指望框架自己优化，得靠人工设边界：
- 把嵌套层级锁死在 ≤3 层：DOM 上最多
<section><div class="grid"> <article class="card">，再往里就用语义化子类（如 <code>card__header）替代.card > header - 禁用框架的全局过渡动画：把
transition: all替成transition: transform 0.2s, opacity 0.2s，其他属性（color、background）不加 transition - 对高频交互元素显式启用合成层：
will-change: transform只加在真正需要动画的元素上（比如下拉菜单、模态框 backdrop），别全页面加 - Bootstrap 的
.d-flex+.flex-column嵌套两层后，再加.justify-content-between，会触发 flex 容器重算；改用单层grid布局 +place-content - Tailwind 的
animate-bounce类内部用transform: translateY()是 OK 的，但animate-pulse依赖opacity+scale，若同时作用于父容器，会波及所有子元素重绘；拆成独立动画层 - 所有框架的
* { box-sizing: border-box }虽然方便，但在万级节点页面中首次解析会明显卡顿；换成只对html或body下关键容器作用 - 打开 Rendering 面板 → 勾选
Paint flashing，悬停/滚动时看是否大面积绿色闪烁；闪烁区域的父级如果用了class="grid grid-cols-4"却还包着三层div，就得砍 DOM - Performance 面板录制操作 → 筛选
Layout事件 → 点开耗时最高的那个 → 看Call Stack是否出现getBoundingClientRect()或offsetHeight；出现就说明 JS 在读取尺寸后立刻写了样式 - 在控制台跑
console.time('layout'); el.offsetWidth; console.timeEnd('layout');，测关键元素是否被意外读取
哪些框架特性必须关掉或替换
某些“方便”功能是性能隐形杀手：
立即学习“前端免费学习笔记（深入）”；
怎么验证改没改对
别靠感觉，用 Chrome DevTools 实锤：
真正难搞的不是怎么写新代码，而是怎么让老项目里的嵌套 DOM 和框架默认样式“解耦”——往往删掉一个无意义的 <div class="wrapper">，比加十个 <code>will-change 更管用。
