原子化CSS是按单一职责输出不可再分的class，如mt-4只管上边距；它不同于手写class，不组合语义、不预设结构，Tailwind通过PostCSS按配置生成原子class，需严格遵循purge、theme.extend等规则确保构建安全。
什么是原子化 CSS，它和手写 class 有什么区别
原子化 CSS 不是“把样式拆小”，而是按单一职责输出不可再分的 class，比如 mt-4 只管上边距、text-center 只管文本居中、bg-blue-500 只管背景色——每个 class 对应一个 CSS 声明，不组合语义、不预设组件结构。
容易踩的坑：有人用 btn-primary 这类带业务含义的 class，这已经脱离原子化原则；也有人把 flex + items-center + justify-between 写满一行当“原子”，其实只是组合调用，没解决重复定义或响应式断点混乱的问题。
PostCSS + Tailwind 是目前最稳的落地路径
Tailwind 不是“UI 框架”，它是基于 PostCSS 的原子化 CSS 生成器。它不提供现成组件，只提供可配置的原子 class 生成规则，所有 class 都来自 tailwind.config.js 中的 theme 和 plugins 定义。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要直接改
node_modules/tailwindcss里的默认配置，所有定制必须走tailwind.config.js - 响应式前缀（如
md:text-lg）依赖theme.screens，删掉某个断点会导致对应前缀 class 彻底不生成 -
content字段必须精确指向模板文件路径，漏写src/**/*.tsx就会丢失 class，不是“没生效”，是压根没生成 - 开发时开
purge: false仅用于调试，上线必须开启purge（v3+ 为content），否则体积爆炸
自定义原子 class 要绕过 @layer，直接 extend theme
想加一个 shadow-card 或 ring-focus？别写 @layer utilities，那属于运行时注入，无法被 PurgeCSS 识别，上线后大概率被删。
正确做法是修改 tailwind.config.js 的 theme.extend：
module.exports = {
theme: {
extend: {
boxShadow: {
card: '0 1px 3px rgba(0,0,0,0.1), 0 1px 2px rgba(0,0,0,0.15)',
},
ringWidth: {
focus: '2px',
}
}
}
}
这样生成的 shadow-card 和 ring-focus 才会被完整纳入构建流程，支持响应式前缀和 PurgeCSS 安全剔除。
用 class 多还是用 @apply 多，取决于维护场景
@apply 是语法糖，本质是把多个原子 class 合并成一个新 class，但它会制造隐性耦合：一旦基础原子 class 名变更（比如升级 Tailwind 版本），@apply 就会失效，且 IDE 很难跳转溯源。
适用场景：
- 高度复用、跨项目一致的视觉单元（如统一表单控件状态），可用
@apply封装，但要写进src/styles/utils.css统一管理 - 页面内临时组合（比如某处需要
flex gap-2 p-3 rounded-lg），直接写 class 更轻量、更易搜索、更利于协作排查 - 绝对不要在组件逻辑里动态拼接
@apply字符串，那等于放弃原子化带来的可预测性
真正难的是设计约束边界：哪些该原子化、哪些该封装、哪些该交由 JS 控制状态——没有银弹，只有根据团队规模和迭代节奏持续校准。
