直接写@media易失控，因断点值重复散落、min/max混用致边界遗漏或重叠；须用map统一管理断点并解耦类型，通过@include responsive(md)语义调用，避免硬编码与嵌套爆炸。
为什么直接写 @media 容易失控
手写一堆 @media (min-width: 768px)、@media (max-width: 1023px) 最终会演变成重复、难维护的碎片。不同组件里反复出现相同断点值，改一个要搜全项目；更糟的是，min-width 和 max-width 混用还容易导致边界重叠或遗漏——比如 768px 到 1023px 和 1024px 之间漏掉 1px，某些设备就卡在“没匹配到任何样式”的状态。
@mixin responsive 必须封装断点逻辑，而非只包 @media
真正有用的 mixin 不是简单套壳，而是把「断点定义」和「媒体查询类型」解耦。推荐用 map 存断点值，再用参数控制是 min-width、max-width 还是区间：
$breakpoints: (
sm: 576px,
md: 768px,
lg: 992px,
xl: 1200px
);
<p>@mixin responsive($key, $type: min) {
@if map-has-key($breakpoints, $key) {
$value: map-get($breakpoints, $key);
@if $type == min {
@media (min-width: $value) { @content; }
} @else if $type == max {
@media (max-width: $value - 1px) { @content; }
} @else if $type == between {
$next: map-next($breakpoints, $key);
@if $next {
@media (min-width: $value) and (max-width: map-get($next, 1) - 1px) {
@content;
}
}
}
}
}</p>
注意：map-next 是 Sass 1.70+ 内置函数，旧版本需自行实现；max-width 减 1px 是为避免和下一个 min-width 断点冲突。
别在 mixin 里硬编码像素值，用语义名代替
写 @include responsive(md) 比 @include responsive(768px) 更安全。原因有三：
- 团队协作时，设计师给的“平板宽度”可能从 768px 改成 780px，改一处 map 即可全局生效
- Sass 编译时能校验 key 是否存在（
map-has-key），而裸数字无法做这种防护 - 响应式逻辑集中在一处，方便加调试开关，比如临时禁用所有
lg及以上样式做回归测试
实际使用时最常踩的坑：嵌套层级与选择器爆炸
很多人习惯这样写：
.card {
width: 100%;
@include responsive(md) {
width: 50%;
}
@include responsive(lg) {
width: 33.333%;
}
}
看起来干净，但编译后会生成两套独立 @media 块，CSS 体积翻倍。更严重的是，如果后续在 .card 内部又嵌套 @include responsive，Sass 会把媒体查询层层包裹，最终产出类似 @media (min-width: 992px) { .card { @media (max-width: 767px) { ... } } } 的非法嵌套。
正确做法是把断点逻辑提到最外层：
.card {
width: 100%;
}
@include responsive(md) {
.card {
width: 50%;
}
}
@include responsive(lg) {
.card {
width: 33.333%;
}
}
这样既保证 CSS 规则扁平，也避免编译器报错。复杂组件建议用 @content + 单独 class 控制，而不是靠嵌套推导。
断点命名是否统一、min/max 边界如何取舍、是否支持暗色模式等媒体特性——这些细节一旦项目变大，就会从“小优化”变成“必填坑”。早约束，晚省事。
