Tailwind CSS 适合什么项目？不适合什么项目？
Tailwind 不是“万能加速器”，它真正提效的前提是：你有至少 3 个中等复杂度页面，且团队愿意统一用原子类表达设计意图。小项目（比如单页登录表单、A/B 测试页）硬套 Tailwind，反而会因全量扫描 content 路径、加载未用类、热更新卡顿而拖慢开发。
- 适合：中后台系统、Next.js/React/Vue 项目、需要高度定制品牌色与间距体系的业务线
- 不适合：仅需兼容 IE11 的老系统、静态营销页（
bootstrap.min.css一行引入更快）、内部脚本工具页（手写style="margin:8px"更直接） - 关键配置必须改：
content要精准限定为["./src/**/*.{js,ts,jsx,tsx}"]，否则扫描node_modules会让构建变慢 2–3 秒 - 默认
preflight（重置样式）可关，换成轻量@layer base { * { margin: 0; } }，能减少约 40% 初始 CSS 体积
Bootstrap 5 的 utility 类为什么有时比手写 CSS 还慢？
表面看 class="d-flex justify-content-between align-items-center" 写得快，但真实代价藏在三处：构建时生成冗余规则、运行时浏览器匹配大量类名、调试时找不到样式来源。尤其当你只用其中 2 个类，却加载了整套 1200+ 条 utility 规则时，性能损耗就实打实发生了。
- 常见错误现象：修改
$spacers后热更新不生效——因为 Bootstrap 的 SCSS 变量嵌套深，缓存没清干净，得删.sass-cache目录重编译 - 使用场景：企业官网、政府门户、对旧版 Chrome/Firefox 兼容性有硬要求的项目
- 性能优化点：用
bootstrap/scss/utilities/_align.scss单独导入需要的模块，而不是整个utilities.scss - 别忽略它仍依赖 jQuery 插件（如 Tooltip），若项目已用 React/Vue，这些 JS 组件基本闲置，纯 CSS 部分才真正可用
Bulma 为什么“零 JS 依赖”反而成双刃剑？
Bulma 纯 CSS 的设计让它集成到任何框架都轻松，但也意味着所有交互逻辑（下拉菜单、模态框、折叠面板）得你自己补 JavaScript 实现。它不是“没交互”，而是把交互责任完全交还给开发者。
- 容易踩的坑：直接复制文档里
<nav class="navbar">...</nav>到 Vue 项目，发现汉堡菜单点不开——因为 Bulma 没提供is-active的 JS 切换逻辑，你得自己写@click="isMenuOpen = !isMenuOpen"并绑定 class - 适用场景：静态站点生成器（如 Hugo、Astro）、内容型博客、强调语义化和可访问性的无障碍项目
- 响应式断点固定为
tablet/desktop/widescreen，不支持自定义媒体查询前缀，想加sm:风格需额外封装 - Flexbox 布局虽现代，但不支持 Grid，复杂仪表盘类布局仍得靠手写
display: grid补足
怎么判断该手写 CSS 还是上框架？关键看这三点
别被“主流框架”带节奏。真正决定选型的不是流行度，而是你当前项目的约束条件。
立即学习“前端免费学习笔记（深入）”；
- 设计系统是否已存在？如果 Figma 设计稿里所有按钮圆角都是
6px、阴影统一为0 1px 3px rgba(0,0,0,0.1)，那手写.btn { border-radius: 6px; box-shadow: 0 1px 3px rgba(0,0,0,0.1); }两秒完事，比查 Tailwind 文档、配theme.extend.borderRadius更快 - 团队是否有共识成本？新人入职要花半天背
flex/justify-center/items-start的组合逻辑，而text-center和text-right这种语义类，学起来几乎无门槛 - 首屏关键 CSS 是否可控？框架注入的样式常阻塞渲染，而手写内联关键样式（如
<style>.hero { background: #fff; }</style>）或用critical CSS提取，更能压住 LCP
最常被忽略的是：框架不是替代 CSS 的工具，而是帮你管理 CSS 复杂度的协作协议。协议本身有开销，协议没对齐时，开销就变成债务。
