真正可维护的响应式方案是用 $breakpoints map + @mixin + @content 三层结构解耦数值、查询逻辑与样式注入，必须用键值对 map（如("sm": 40em, "md": 48em)），单位用 em 保证缩放响应性，@mixin 内仅用 min-width 实现清晰向上覆盖，@content 支持嵌套注入且作用域隔离。
直接写 @media 硬编码断点值（比如 @media (min-width: 768px)）是后期维护最头疼的源头——改一个数值，全项目搜、替、验，漏一处就错一片。真正可维护的方案，是用 $breakpoints map + @mixin + @content 三层结构，把“数值”“查询逻辑”“样式注入”解耦。
为什么必须用 map 而不是变量或 list
SCSS 的 map-get() 只认 map 类型。你写 $sm: 768px，调用 @include respond-to("sm") 就会报错或返回 null；写 (576px, 768px) 这种 list，根本没法按名字查值，@include respond-to("md") 直接失效。IDE 也无法跳转到定义处，协作时谁也不知道 $md 到底对应哪一层设备。
-
$breakpoints必须是键值对形式：("sm": 576px, "md": 768px, "lg": 992px) - 键名推荐
"sm"而非"mobile"：语义稳定，不绑定具体设备 - 值必须带单位：
576px，不能写576，否则编译报Invalid null operation
@mixin respond-to($breakpoint) 里只用 min-width 的原因
用 @media (min-width: 768px) 天然支持“向上覆盖”，边界清晰。如果混用 max-width，比如同时写 @media (max-width: 767px) 和 @media (max-width: 1023px)，768–1023px 区间两个都匹配，浏览器取后声明的规则，但你本意可能是让这个区间单独生效——这时就得手动加 and (min-width: 768px)，反而更啰嗦且易错。
- 所有断点按升序排列：
sm → md → lg → xl - 桌面端样式写在默认层（无媒体查询），移动端覆盖逻辑全交给
@include respond-to("sm")往上叠加 - 别在 mixin 内部写
max-width查询——它和min-width混用极易触发重叠或遗漏
@content 不是语法糖，是嵌套能力的关键
没有 @content 的断点 mixin 只能返回字符串，你得自己拼样式块，难读又易出错。加上 @content 后，调用时大括号里的内容会被原样注入到生成的 @media 块内部，包括嵌套选择器、伪类、其他 mixin，甚至变量计算。
-
@content必须出现在 mixin 定义里，且只能出现一次 - 调用时必须用大括号包裹内容：
@include respond-to("md") { padding: 1.5rem; }，不能省略{} - 不能在
@content外部访问调用作用域里的局部变量——这是作用域隔离机制，不是 bug - 支持透传
&:hover、&::before等，不会破坏父选择器层级
单位用 em 而不是 px 的实际影响
Sass 不感知 html 的 font-size 变化。纯 px 断点在用户缩放、动态根字号（如 rem 方案）、或强制字体放大时会失效。48em 对应 768px @16px 基准，但当根字号变成 20px，48em 就自动变成 960px，断点行为才真正响应视口。
- 断点值统一用
em：("sm": 40em, "md": 48em, "lg": 64em) - 不要在
@mixin里拼字符串，用#{map-get($breakpoints, $name)}安全取值 -
@include breakpoint(md)不生效？先检查是否写在顶层（没挂选择器）、是否被display: none或visibility: hidden视觉隐藏了
最常被忽略的是：断点逻辑不该侵入组件内部。一个按钮组件自己写 @include respond-to("md")，等于把响应式控制权交给了它自己；而实际应该由外层容器决定何时启用该组件的“大屏变体”。断点 mixin 是工具，不是决策者。
