我已经使用SCSS( SASS) 多年了，并且还Styled-Components用于一些项目，一些大型项目。

我喜欢两者，Styled-Components对我来说，感觉就像向前迈出了一步：

样式化组件 - 优点

1. 完全造型隔离；防止在团队中工作时潜在的错误，当一个团队成员永远不能覆盖另一个团队成员的风格时。（除非多个地方共享相同的样式组件）
2. 无需手动处理类名，因为它们会自动生成（恕我直言，选择名称的组件比类名更容易）

3. 我发现在JSX文件本身中使用CSS更容易（多年来反对我的判断）

4. 在样式中轻松使用 javascript 变量（消除对 2 组主题变量的需要）

样式组件 - 缺点

1. 每个样式组件都是另一个包装函数，许多样式组件意味着更多的功能，这意味着效率较低，因为所有代码都需要“编译”等等。
2. 最大的缺点：对样式的更改需要重新编译包，并且应用程序的状态可能会重置。

只能在某些情况下而不是全部情况下这样看待缺点。

SCSS/LESS优点可以被视为与上面列出的缺点相反，同时还有一些缺点，例如在使用变量时混合和更快的开发（恕我直言）。定义局部选择器变量可能会变得“丑陋”：

比较这些简化的例子：

SCSS 例子：

.icon{
  $size: '20px';
  width: $size;
  height: $size;
  margin-left: $size/2;
}

Styled-Components 本地范围示例：

const Icon = styled.i(props => {
  const size = 20; // easier to use Number instead of String for calculations 
  return `
    width: ${size}px;
    height: ${size}px;
    margin-left: ${size/2}px;
`});

显然，变量可以在Icon样式化包装器之外定义，然后在内部使用，但这不会使其孤立，因为样式化组件 CSS 可能由样式化的子组件组成，看起来更像 CSS：

const Header = styled.header`
   > ul{
     ...
   }

   li{
     ...
   }

   img{...}

   navigation{...}
`

并非总是希望将每个单独的 HTML 元素提取到其自己的样式组件中。它主要用于在应用程序中重复或可能重复的组件。

关于SASS混合，它们可以转换为javascript函数，所以这里SASS没有太大的优势。

总体而言，使用 Styled-Components 既有趣又容易，但有一个副作用，即样式和框架/组件之间的耦合更紧密，而且显然会造成一些性能损失（实际上并不会减慢您的速度，但仍然如此）。

浏览器进化为将 CSS 与 Javascript 解析分开来解析，为什么我们试图偏离这一点而将所有内容都放在 Javascript 中？

当您混合使用 Javascript 和 HTML（即 JSX），然后混合使用 CSS（JSS 或其他）时，您将组件变成一个适合单个文件的可靠module。您不再需要将样式保存在单独的文件中。

然后，功能魔法发生了：由于 JSX 是返回“HTML”的原始数据的纯函数（不是真的），同样的方式 CSS-in-JS 是返回“CSS”的纯函数或原始数据（也不是真的） ）。从这一点来看，我认为关于 JSX和CSS-in-JS 都值得一读。

Styled-component CSS 将其 javascript 库发送到客户端，它实际上在运行时解析样式，并<style />在每个组件按需加载时放入标签。这意味着额外的负载和逻辑最终会影响浏览器的执行周期。

不仅在运行时。因为 CSS-in-JSS 只是一个返回 CSS 的数据函数，所以你可以在任何平台上使用它。以 Node 为例，添加SSR，然后您将style元素在响应正文中传递给浏览器，因此解析就像在传递 CSS 的原始情况下发生的那样。

为什么需要这个？

因为它在开发中很方便，就像 React 或 Redux 一样，就像 jQuery 一样，就像任何其他 lib 一样，它以网络负载和浏览器性能为代价。

你拿图书馆是因为它解决了一个问题。如果似乎没有问题，为什么要使用库，对吗？

<style />在 head 标签中连续计算的样式文本是否会导致浏览器回流/重绘？

有这么多的事情，力回流。

浏览器很聪明。如果样式没有改变，他们甚至不会尝试重新粉刷。这并不意味着他们不计算差异，这会消耗 CPU 时间。

对样式（重新）计算的范围和复杂性有一个很好的介绍，非常值得阅读以更深入地了解该主题。