Sass编译后媒体查询不会自动合并，因其@media仅是语法糖、编译器不做语义分析，导致相同断点重复输出；需借助smqc工具、PostCSS插件或@mixin集中管理实现CSS层合并。
直接合并多个相同断点的媒体查询能减少最终CSS文件体积和解析开销，但必须通过编译时工具实现——Sass本身不自动合并@media块，@media只是原样输出，靠人工或插件处理。
为什么Sass编译后媒体查询不会自动合并
Sass的@media嵌套只是语法糖，编译器不做逻辑合并。比如两个地方都写了@media (min-width: 768px)，最终CSS里就是两段独立规则，浏览器得分别解析、匹配、构建CSSOM。
- 现象：Lighthouse报告“Reduce unused CSS”警告，DevTools里Style Editor看到重复断点
- 根本原因：Sass不分析语义，只做文本拼接；
@import导入的partial里各自定义的@media互不可见 - 影响：首屏关键CSS体积虚增，尤其在组件库+业务样式混合场景下，
@media可能被复制10次以上
用 sass-media-query-combiner 命令行工具合并
这是目前最轻量、侵入性最小的方案，适合已存在大量Sass文件但不想重构结构的项目。
- 安装：
npm install -g sass-media-query-combiner - 运行：
smqc src/styles.scss dist/style.css，它会扫描所有@media块，按条件字符串归并相同断点内的规则 - 注意：
smqc不处理@import路径重写，确保输入文件已完整编译（即先用sass命令生成中间CSS，再喂给smqc） - 兼容性：只支持标准
@media (min-width: Npx)写法，对and、not复合条件支持有限，避免写@media (min-width: 768px) and (orientation: landscape)这类多条件组合
在构建流程中集成PostCSS合并方案
比单独CLI更稳定，能与现有打包流程（Webpack/Vite）无缝衔接，且支持更多媒体查询变体。
立即学习“前端免费学习笔记（深入）”；
- 安装插件：
npm install postcss postcss-media-minmax postcss-combine-media-query --save-dev - 配置
postcss.config.js：module.exports = { plugins: [ require('postcss-combine-media-query'), require('cssnano') // 后续压缩 ] } - 关键限制：
postcss-combine-media-query只合并完全相同的媒体查询字符串，@media screen and (min-width: 768px)和@media (min-width: 768px)（缺screen）会被视为不同断点，务必统一写法 - 性能提示：该插件在CSS输出阶段运行，不影响Sass编译速度，但会增加构建总时长约5–10%，小项目可忽略
手动组织Sass结构规避重复生成
最可控的方式，但依赖团队规范，适合新项目或重构窗口期。
- 把所有响应式规则集中到
_breakpoints.scss，用@mixin封装断点逻辑，例如：@mixin for-tablet { @media (min-width: 768px) { @content; } } - 禁止在组件partial里直接写
@media，全部通过@include for-tablet { ... }调用 - 配合
@use作用域控制：每个组件@use自己的断点mixin，避免全局污染，同时保证同一断点只被引入一次 - 风险点：如果多个组件都
@include for-tablet且内部规则无重叠，最终CSS仍会重复——需配合构建时CSS去重（如cssnano的mergeLonghand选项）
真正起效的合并必须发生在CSS字符串层面，而不是Sass源码层；工具链选型要匹配项目现状——老项目用smqc快速见效，新项目优先设计@mixin驱动的断点体系，否则光靠插件也救不了散落在20个文件里的@media (min-width: 768px)。
