重复媒体查询导致维护困难，主要因断点修改需全局替换、样式分散难对齐、编译后冗余膨胀；应抽离断点为变量和@mixin respond-to($breakpoint)，由调用方传入内容，避免嵌套@media，并统一模块化管理与导入。
为什么重复的媒体查询会让CSS越来越难维护
重复写 @media (max-width: 768px) 不只是手累，更会埋下三类隐患：一是改断点要全局搜索替换，漏一处就错一片；二是多个选择器在相同断点下调整 padding / font-size / display，却分散在不同文件里，后期对齐样式成本飙升；三是编译后 CSS 里出现十几段一模一样的 @media 块，体积膨胀且浏览器解析效率下降。
用 @mixin 封装断点逻辑，但别嵌套在 mixin 里
常见错误是把 @media 写进 @mixin 内部，比如：
@mixin mobile-only {
@media (max-width: 768px) {
display: none;
}
}
这会导致调用方失去控制权——你没法在同一个断点下把 .header 和 .nav 的行为合并写，也无法叠加其他规则。正确做法是把断点本身抽成可复用的 mixin，内容由调用者决定：
-
@mixin respond-to($breakpoint)只负责判断并输出对应媒体查询，@content由外部传入 - 断点值统一用变量定义：
$breakpoint-mobile: 768px，避免字面量散落 - 调用时保持语义清晰：
@include respond-to(mobile) { padding: 8px; }，而不是@include mobile-padding这种绑定过死的名字
@use 怎么配合断点模块不报错
如果你把断点变量和 @mixin respond-to 放在 _breakpoints.scss 里，用 @use "breakpoints" 后直接写 @include respond-to(mobile) 报错，说明两件事：
- 没导出 mixin：
_breakpoints.scss末尾必须加@forward "breakpoints" with (respond-to as respond-to);或显式@use "breakpoints" as bp;再写@include bp.respond-to(mobile) - 变量未被引用：如果
respond-to内部用了$breakpoint-mobile，它必须在同一模块中定义或通过@use导入，不能靠全局隐式注入 - 路径写错：Sass 不自动补
.scss，但会找_breakpoints.scss；确保@use "breakpoints"的相对路径是从当前文件到该文件的正确路径
合并相同断点的媒体查询，不是靠工具而是靠组织方式
很多人等 PurgeCSS 或 PostCSS 插件来“合并媒体查询”，其实 Sass 层就能解决。关键不是语法技巧，而是文件组织：
- 把同一业务区域的响应式规则集中在一个文件里，比如
_card.scss包含 card 默认样式 + 所有断点下的变体，而不是让_typography.scss和_spacing.scss各自写一遍@media (max-width: 768px) - 禁用跨模块响应式：A 组件的 mobile 规则不要塞进 B 组件的 mixin 里，否则修改 A 会意外影响 B 的输出
- 慎用
@content多层嵌套：三层以上@include套@include再套@media，调试时根本分不清哪条声明来自哪一层
真正难的不是写对一个 @mixin，而是让所有开发者在新增样式时，下意识把响应式规则“归位”到对应组件文件里——这需要目录结构、命名约定和 Code Review 协同约束，不是单靠语法能兜住的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
