17370845950

手写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 文件，不注入
• 支持 JS 表达式：color: ${props => props.primary ? '#007bff' : '#6c757d'};，不用拆成多个 class
• 热更新快：改样式保存即生效，不用等整个模块重载

import { css } from 'linaria';
const button = css padding: 0.5rem 1rem; border-radius: 4px; background-color: ${props => props.primary ? '#007bff' : '#6c757d'}; color: white; ;

别忽略浏览器原生能力，比如 :has() 和 color-scheme

很多“必须 JS 控制”的场景，其实 CSS 已经能解了。比如以前要监听 prefers-color-scheme 切换主题，现在直接：

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #1e1e1e;
    --text: #e6e6e6;
  }
}
/ 更进一步，用 color-scheme 告诉浏览器表单控件也走暗色 /
: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 代码的机会。最容易被忽略的，其实是“先确认浏览器能不能做”，而不是“赶紧找插件”。