SCSS混入中重复同尺寸媒体查询是否存在问题？

我正在把CSS转成SCSS，用混入处理媒体查询，代码示例如下：

@mixin for-phone-only {
  @media screen and (max-width: 700px) {
    @content;
  }
}

.app_sidebar {
  background-color: set-color(primary, 900);
  box-shadow: 0 0 15px 0 set-color(primary, 100);
  flex: 20%;
  z-index: 1;

  @include for-phone-only {
    flex-direction: column;
  }
}

.app_main_block {
  background-color: #1e98d7;
  
  @include for-phone-only {
    flex-direction: column;
  }
}

现在发现每个选择器都会生成同尺寸的独立媒体查询，而不是合并成一个。虽然功能正常，但想知道这种重复会不会有问题、性能影响或潜在弊端？要不要关注这种冗余，还是说在Sass里这是可接受的做法？另外想了解相关最佳实践，或者Sass里优化媒体查询、避免重复的替代方案。

我已经看过一些相关文档和问题，但没找到合适答案。

一、重复媒体查询的实际影响 #

1. 文件体积：重复的媒体查询会增加CSS文件大小，尤其在大型项目中频繁使用时，冗余代码会累积导致文件体积变大，影响加载速度。不过现代构建工具（如Webpack、Vite）的CSS压缩插件（如cssnano）会自动合并相同的媒体查询，生产环境下这个问题会被缓解。
2. 浏览器性能：浏览器处理重复媒体查询时不会有额外性能开销——它会将同规则的媒体查询视为同一组，不会重复解析，前端运行时性能基本不受影响。
3. 代码可维护性：这种“内联式”写法的好处是把元素的响应式样式和基础样式放在一起，修改时无需跳转查找；但如果项目中有多个断点混入，可能会增加管理成本，不过单就重复媒体查询本身，对维护的影响不大，除非你追求极致的代码整洁。

二、要不要关注这种冗余？ #

• 开发阶段：完全不用纠结，这种写法的开发体验更好，能让你专注于单个元素的样式逻辑，不用来回切换位置写响应式代码。
• 生产阶段：如果构建流程没有配置CSS压缩合并，确实需要处理；但现在主流构建工具都自带这个优化，生产环境下最终的CSS会是合并后的版本，无需手动操心。

三、优化媒体查询的替代方案 #

如果想在编译阶段就合并同断点的媒体查询，有几种办法：

1. 集中式编写媒体查询 #

放弃内联混入的写法，把同一断点的所有样式集中写在一个媒体查询里：

.app_sidebar {
  background-color: set-color(primary, 900);
  box-shadow: 0 0 15px 0 set-color(primary, 100);
  flex: 20%;
  z-index: 1;
}

.app_main_block {
  background-color: #1e98d7;
}

@media screen and (max-width: 700px) {
  .app_sidebar {
    flex-direction: column;
  }
  
  .app_main_block {
    flex-direction: column;
  }
}

优点是编译后没有重复媒体查询，代码更紧凑；缺点是响应式样式和基础样式分离，维护时需要跨位置查找，开发体验不如内联写法。

2. 使用Sass的@extend或占位符 #

用占位符定义断点样式，让多个选择器继承：

%phone-only-flex-column {
  @media screen and (max-width: 700px) {
    flex-direction: column;
  }
}

.app_sidebar {
  background-color: set-color(primary, 900);
  box-shadow: 0 0 15px 0 set-color(primary, 100);
  flex: 20%;
  z-index: 1;
  @extend %phone-only-flex-column;
}

.app_main_block {
  background-color: #1e98d7;
  @extend %phone-only-flex-column;
}

编译后会生成合并的媒体查询：

@media screen and (max-width: 700px) {
  .app_sidebar, .app_main_block {
    flex-direction: column;
  }
}

这种方式兼顾了部分开发体验和编译后的代码整洁，但仅适用于多个元素响应式样式相同的场景。

3. 使用PostCSS插件 #

如果仍想保留内联混入的写法，同时在编译阶段合并媒体查询，可以用PostCSS的postcss-combine-media-query插件。它会自动扫描CSS文件，合并相同的媒体查询，无需改变开发写法，只需在项目中安装配置即可。

总结 #

• 开发阶段优先选择内联混入写法，提升开发效率；
• 生产阶段依赖构建工具的CSS压缩插件或PostCSS插件自动合并重复媒体查询；
• 如果追求编译后代码的极致整洁，且能接受开发体验的小牺牲，可以用集中式编写或**@extend占位符**的方式。

内容的提问来源于stack exchange，提问作者AlgoPro