@import 不适合做原子类汇集，因为它会阻塞渲染、无法 Tree Shaking、不支持条件导入，且与 Tailwind 的 content 扫描机制冲突；Tailwind 通过配置、HTML 编写和构建闭环，按需生成原子类。
为什么 @import 不适合做原子类汇集
它会阻塞渲染，且无法被现代构建工具（如 Vite、Webpack）有效提取或 Tree Shaking。浏览器遇到 @import 时必须串行请求并解析引入的 CSS 文件，哪怕你只是想用其中一两个类，整个文件也得下载+解析完才能继续——这和原子类“按需使用”的初衷直接冲突。
常见错误现象：npm run build 后发现所有原子类全打进一个 CSS 文件里，体积翻倍；开发时样式加载明显卡顿；class="text-sm font-bold p-4" 对应的规则在 DevTools 里找不到，但又莫名生效（其实是被其他 @import 覆盖了）。
- 所有
@import都在 CSS 解析阶段执行，不支持条件导入或动态路径 - PostCSS 插件（如
postcss-import）虽能提前处理，但本质仍是静态合并，无法识别 HTML 中实际用了哪些类 - 和 Tailwind 的
content配置完全不兼容——Tailwind 需要扫描源码提取用到的类，@import引入的原子类根本不会被扫描到
Tailwind 是怎么真正管好原子类的
它不靠 @import，而是把原子类当作“可生成的函数”来处理：写配置、写 HTML、跑构建，三步闭环。核心是 content 字段告诉 Tailwind 去哪找用到的类名，再由 purge（或 content + darkMode 等）决定最终输出哪些规则。
使用场景：你写 class="bg-blue-500 hover:bg-blue-600"，Tailwind 就只生成这两条背景色规则，哪怕你配置了 blue-50 to blue-900 全套色阶。
立即学习“前端免费学习笔记（深入）”；
-
content必须包含所有可能写 class 的文件路径，比如./src/**/*.{js,ts,jsx,tsx,html} - 不要在 CSS 文件里手动写原子类（如
.p-4 { padding: 1rem; }），那会绕过 Tailwind 的提取逻辑，导致冗余或缺失 - 自定义原子类要用
theme.extend或addUtilities，而不是@import一堆散装 CSS
如果非要用纯 CSS 写原子类，怎么避免 @import 坑
可以，但得放弃“汇集”思维，改用构建时内联或条件注入。关键是让每个原子类都独立可识别、可剔除。
性能影响：纯 CSS 原子类打包后体积容易失控，尤其当颜色、间距、断点组合爆炸时。浏览器解析大量单规则 CSS 的开销，比解析少量复合规则更高。
- 用 PostCSS 插件（如
postcss-preset-env+postcss-custom-properties）把变量抽成:root，再用calc()动态算值，减少规则数量 - 把原子类按功能拆成小文件（
spacing.css、typography.css），用构建脚本按需拼接，而非运行时@import - 绝对不要在
index.css里写@import './atoms/*.css';—— glob 模式不被原生 CSS 支持，依赖构建工具就等于放弃了“纯 CSS”前提
HTML 中 class 名写错时，为什么 Tailwind 不报错
因为 Tailwind 不在运行时检查 class，它只扫描源码字符串。写成 class="text-blur-500" 这种错名，构建时就直接忽略，不会生成对应 CSS，也不会警告——看起来像“样式失效”，其实是“压根没生成”。
容易踩的坑：开发时本地看不出来，上线后才发现文字颜色没变，查半天发现是拼错了 blur 而不是 blue；或者用了未启用的插件功能（比如 aspect-ratio 但没开 @tailwindcss/aspect-ratio）。
- 开启
tailwindcss-lint或 VS Code 的 Tailwind CSS IntelliSense 插件，实时标红非法 class - 在
tailwind.config.js的content里确保包含所有模板文件，否则扫描不到，等于“写了也白写” - 慎用
!important后缀（text-red-500!），它会强制生成带!important的规则，破坏层叠逻辑，调试时极难定位
@import 能解决的。 
