Tailwind 的 CSS 体积优势仅在正确配置 content 扫描并启用 purge 时成立，否则未用类全量保留；其零 JS 开销、毫秒级热更新和易做关键 CSS 提取是性能关键，但所有优势均依赖合理配置与使用。
Tailwind 的 CSS 体积比 Bootstrap 小得多，但前提是正确配置
默认安装的 Bootstrap（含 JS + 所有 CSS）gzip 后约 20–25 KB；而未精简的 Tailwind（tailwindcss 默认配置 + 全量类）生成的 CSS 可能超过 3 MB —— 这不是 bug，是误用。Tailwind 的体积优势只在启用 content 扫描 + purge（现为 content 配置项）后才成立。
- 必须在
tailwind.config.js中准确声明 HTML/JSX 文件路径，例如：content: ["./src/**/*.{js,jsx,ts,tsx,html}"] - 不配置
content或路径遗漏，会导致未使用的 utility 类全部保留，打包出巨无霸 CSS - Bootstrap 没有“扫描+剔除”机制，体积固定，但可通过自定义构建（如只 import 需要的 SCSS 模块）减小到 ~8 KB gzip
运行时性能：Tailwind 几乎零 JS 开销，Bootstrap 依赖大量 DOM 操作
Bootstrap 的 Modal、Dropdown、Tooltip 等组件默认绑定事件监听、操作 DOM 属性、处理 focus/scroll/resize，这些在页面加载后持续占用主线程。Tailwind 本身不提供 JS 行为，所有交互逻辑需自行实现（或搭配 Alpine、React 等），因此没有隐藏的运行时成本。
- 如果你只用 Bootstrap 的 CSS 类（比如
btn btn-primary），禁用其 JS 包，性能可接近 Tailwind - 但一旦启用
bootstrap.js或通过 data-bs-* 属性触发组件，就会引入 ~12 KB（gzip）JS，并在初始化时遍历整个 DOM 查找目标元素 - Tailwind 用户常误以为“没 JS 就一定快”，结果自己手写的
document.addEventListener('click', ...)逻辑存在重复绑定或内存泄漏，反而更慢
构建速度和热更新体验差异明显
Tailwind 在 Vite / Next.js 等现代工具链中热更新极快（毫秒级），因为只重生成用到的类；Bootstrap 的 SCSS 编译（尤其带 @import 多层嵌套时）常需 300–800 ms，且每次改变量都会触发全量重建。
- Tailwind 的
watch模式只读 HTML/JSX，不解析 CSS，响应更快 - Bootstrap 项目若未拆分
_variables.scss和_mixins.scss，一个颜色变量改动可能让整个bootstrap.css重编译 - 注意：Tailwind 的 JIT 引擎（v3.0+ 默认）在首次启动时略慢，但后续编辑几乎无感；旧版（v2.x）的 AOT 模式反而更卡
首屏渲染阻塞风险：两者都可能因 CSS 加载方式翻车
无论 Bootstrap 还是 Tailwind，只要把全部样式打包进一个 style.css 并通过 <link rel="stylesheet"> 同步加载，就会阻塞渲染。区别在于：Tailwind 更容易被拆成按需加载的原子块（比如用 @layer + @apply 提取关键 CSS），而 Bootstrap 的栅格和工具类深度耦合，难做细粒度提取。
立即学习“前端免费学习笔记（深入）”；
- 不要把 Tailwind 的完整 CSS 放在
<head>；优先用critical CSS提取首屏需要的类（如container mx-auto flex），其余异步注入 - Bootstrap 官方不提供 critical CSS 提取方案，社区插件（如
critical）对它的 SCSS 输出支持有限，容易漏掉媒体查询内的规则 - 真正影响用户感知的是「CSS 文件是否包含未渲染内容所需的样式」，而不是框架名字——哪怕你用 Tailwind，如果首页用了
md:hidden lg:block却没加载对应断点类，照样闪动或错位
Tailwind 的性能优势不是天生的，它藏在配置里、构建链路里、甚至你的 HTML 文件组织方式里。很多人测出来 Tailwind 更慢，问题不在框架，而在忘了删掉 content 配置里的 *<em>/</em>.html 通配符，或者把整个 node_modules 路径塞进了扫描范围。
