只有 postcss-combine-media-query 能真正合并完全相同的媒体查询，需显式引入并置于 postcss-nested 等插件之后，确保输入 css 已展平；开发环境不建议启用，仅用于生产构建。
PostCSS插件选哪个才能合并媒体查询
能真正合并重复媒体查询的，只有 postcss-combine-media-query。其他常见插件如 cssnano 默认不开启该功能，postcss-preset-env 也不处理合并逻辑——它只负责语法降级。
注意：这个插件只合并「完全相同」的媒体查询条件，比如两个 @media (min-width: 768px) 才会合，而 @media screen and (min-width: 768px) 和 @media (min-width: 768px) 被视为不同，不会合并。
- 安装命令：
npm install postcss-combine-media-query --save-dev - 在 PostCSS 配置中显式引入：
require('postcss-combine-media-query')，不能只靠cssnano的 preset 自动启用 - 它必须放在
postcss-nested或postcss-mixins等生成嵌套规则的插件之后，否则会漏掉动态生成的媒体查询
为什么写了合并插件却没生效
最常见原因是 CSS 源码里媒体查询被包裹在嵌套结构中，而插件默认不深入解析嵌套块。比如用 postcss-nested 写的：
Component {
@media (min-width: 768px) { color: red; }
@media (min-width: 768px) { font-size: 16px; }
}
这段代码在插件运行时仍为两个独立的 @media 块（只是缩进不同），但插件无法识别它们属于同一父级、可合并。解决方法是确保插件执行顺序正确，并确认输入 CSS 已被完全展开为扁平结构。
- 检查构建流程：用
postcss-reporter或临时加console.log输出中间 CSS，确认媒体查询是否已“展平” - 避免在
@media内部再嵌套@media，postcss-combine-media-query不处理嵌套媒体查询 - 如果用 Sass/Less 编译后走 PostCSS，确保预处理器已将嵌套媒体查询转成标准 CSS 格式
合并后样式覆盖顺序会不会出问题
不会改变层叠顺序——合并只是把多个同条件规则体拼进一个 @media 块，等价于手写合并后的结果。浏览器解析时仍按源码顺序应用规则，和拆开写没有区别。
但要注意：如果原始 CSS 中存在不同 specificity 的选择器，在合并后依然保留各自权重，不会因合并而提升或降低优先级。
- 例如：
.btn { @media (prefers-reduced-motion) { animation: none; } }和button { @media (prefers-reduced-motion) { animation: none; } }合并后仍是两条独立声明，顺序不变 - 真正影响层叠的是选择器本身，不是
@media块的数量 - 如果你依赖媒体查询块的顺序来控制某些 hack（比如用
@media all {}覆盖前面规则），合并可能意外改变行为——这种写法本身就不可靠，应避免
要不要在开发环境也启用媒体查询合并
不建议。合并会抹平源码结构，导致 DevTools 中定位样式困难：点击某个声明，跳转到的可能是合并后的大块 @media，而非原始文件对应行。
而且开发阶段更需要快速验证响应式断点，分散的媒体查询反而便于调试。
- 只在生产构建（
mode === 'production'）中启用postcss-combine-media-query - 若用 Webpack，可在
MiniCssExtractPlugin的 options 里根据环境开关插件 - Vite 用户注意：
vite build默认不启用该插件，需手动在css.postcss.plugins中配置条件加载
真正难的不是加插件，而是确认你的 CSS 构建链路里每一步输出的都是「可合并形态」——从预处理器到 PostCSS 插件顺序，再到最终产物，中间任何一环卡住，合并就静默失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
