SCSS中媒体查询需嵌套使用&显式引用父选择器，配合$breakpoints变量和@mixin统一管理断点，坚持移动优先的min-width策略，并避免嵌套过深或硬编码，以保障语义正确、可维护与性能。
SCSS 里写媒体查询不是简单套 @media 就完事——直接嵌套、用变量控制断点、避免重复条件，才是高效写法。否则容易写出一堆散落各处、无法维护的 @media (min-width: 768px)。
SCSS 中如何安全嵌套 @media 规则
原生 CSS 不允许在选择器内部写 @media，但 SCSS 支持。关键在于：嵌套后生成的 CSS 必须保持语义正确，不能意外提升选择器权重或漏掉父级上下文。
- 写法必须是
&显式引用父选择器，例如：.card { padding: 1rem; @media (min-width: 768px) { &__title { font-size: 1.5rem; } } }这样编译后是.card .card__title，而非错误的.card__title单独出现 - 不要在嵌套中省略
&写成.card__title，否则它会脱离父级作用域，变成全局选择器 - 嵌套层级过深（超过 3 层）会让生成的 CSS 选择器过长，影响性能和可读性，建议拆到顶层或用
@extend抽离共用样式
用 $breakpoints 变量统一管理断点
硬编码 768px、1024px 在多个文件里，改一个漏十个。SCSS 的变量 + @mixin 是标准解法。
- 定义断点映射：
$breakpoints: ( sm: 576px, md: 768px, lg: 992px, xl: 1200px, xxl: 1400px );
- 封装响应式 mixin：
@mixin media-breakpoint-up($name) { @media (min-width: map-get($breakpoints, $name)) { @content; } } - 使用时清晰表达意图：
.header { font-size: 1rem; @include media-breakpoint-up(md) { font-size: 1.25rem; } @include media-breakpoint-up(xl) { font-size: 1.5rem; } }
@media 条件里该用 min-width 还是 max-width
这不是风格问题，而是逻辑陷阱。混用会导致样式覆盖不可控，尤其在多断点叠加时。
立即学习“前端免费学习笔记（深入）”；
- 推荐「移动优先」策略：全部用
min-width，从小屏往上增强。这样浏览器按顺序解析，后写的规则自然覆盖前写的，符合 CSS 层叠逻辑 - 如果混用
min-width: 768px和max-width: 1023px，当视口正好是1024px时，可能某个规则意外失效——因为max-width: 1023px不再匹配，而下一个min-width: 1024px又没写全 -
device-width基本不用：它读取的是设备物理宽度（如 iPhone 14 是 390px），但用户缩放、横竖屏切换都会让这个值失真；一律用width或min-width（即视口 viewport 宽度）
SCSS 编译后媒体查询合并问题
你写了 5 个 @include media-breakpoint-up(md)，结果编译出 5 个独立的 @media (min-width: 768px) 块？这不是 bug，是默认行为。但大量重复 @media 块会增大 CSS 体积，且不利于后期提取打印样式或暗色模式规则。
- 启用
media-queries合并插件（如sass-embedded1.7+ 默认支持），或用 PostCSS 插件postcss-combine-duplicated-selectors后处理 - 更可控的方式：把所有同断点下的规则集中到一个顶层
@media块里，用@forward+@use拆分模块，再由主文件统一包裹 - 注意：Sass 不会自动合并跨文件的相同媒体查询，这点常被忽略
真正麻烦的不是写几个 @media，而是断点命名是否一致、单位是否统一（px 还是 rem）、是否考虑了 hover 或 prefers-reduced-motion 这类辅助功能特性——这些不体现在编译结果里，但决定实际体验。
