手写CSS变慢不是能力问题，而是现代项目需自动化：Tailwind+PostCSS处理原子样式与兼容性，Linaria解决动态逻辑，:has()等原生特性可替代JS逻辑。
为什么手写 CSS 越来越慢？不是你不行，是现代项目压根不靠手写
现在一个中等复杂度的 React/Vue 项目，className 动辄带 3–5 个条件拼接，响应式要写 @media 嵌套，主题切换还要加 [data-theme="dark"] 前缀——这些都不是“写得慢”，而是“不该这么写”。CSS 自动化工具不是锦上添花，是把重复劳动从人脑里卸载出去。
PostCSS + Tailwind 是目前最稳的组合，别被“原子类”吓住
Tailwind 不是让你在 HTML 里堆 class="text-sm font-bold p-2 bg-blue-500 hover:bg-blue-600 rounded"，而是配合 @apply 和 @layer 封装语义化类。真正省时间的是它背后的 PostCSS 生态：
-
postcss-nested支持真正的嵌套语法，不用手动拼选择器前缀 -
postcss-preset-env直接写color: hsl(200 100% 50%)或gap: 1rem，自动补全旧浏览器需要的display: -ms-grid -
cssnano在构建时压缩、合并重复声明，比手写“精简 CSS”更可靠
/* tailwind.config.js */
module.exports = {
content: ["./src/**/*.{js,jsx,ts,tsx}"],
theme: {
extend: {
colors: {
brand: "var(--color-brand, #3b82f6)",
},
},
},
plugins: [require("@tailwindcss/forms")],
}用 CSS-in-JS 工具（如 Linaria）绕过构建链路卡点
当你改一个按钮颜色要等 Webpack 重编译 3 秒，或者调试时发现 DevTools 里 class 名是 _1x9kL 完全看不懂——说明你卡在了构建和调试环节。Linaria 的优势在于：
- 运行时零开销：所有样式在构建时提取为真实 CSS 文件，不注入
<style></style> - 支持 JS 表达式：
color: ${props => props.primary ? '#007bff' : '#6c757d'};，不用拆成多个 class - 热更新快：改样式保存即生效，不用等整个模块重载
import { css } from 'linaria';
<p>const button = css<code> padding: 0.5rem 1rem; border-radius: 4px; background-color: ${props => props.primary ? '#007bff' : '#6c757d'}; color: white; </code>;立即学习“前端免费学习笔记（深入）”；
别忽略浏览器原生能力，比如 :has() 和 color-scheme
很多“必须 JS 控制”的场景，其实 CSS 已经能解了。比如以前要监听 prefers-color-scheme 切换主题，现在直接：
@media (prefers-color-scheme: dark) {
:root {
--bg: #1e1e1e;
--text: #e6e6e6;
}
}
<p>/<em> 更进一步，用 color-scheme 告诉浏览器表单控件也走暗色 </em>/
:root {
color-scheme: light dark;
}又比如父元素根据子元素状态变样式，过去只能靠 JS 加 class，现在：
.card:has(.delete-btn:hover) {
box-shadow: 0 0 12px rgba(0,0,0,0.2);
}这类特性不需要任何构建工具，但很多人根本没查 MDN 就去配一套复杂的主题系统。
自动化不是堆工具，是识别哪些事本就不该人干。Tailwind 处理原子样式，PostCSS 处理兼容性，Linaria 处理动态逻辑，而 :has() 这类新特性，是直接删掉一整段 JS 代码的机会。最容易被忽略的，其实是“先确认浏览器能不能做”，而不是“赶紧找插件”。
