最稳方案是用@mixin respond-to($name)配合$breakpoints map，因map-get只认map类型，变量或list会导致查询失败、IDE无法跳转；必须用带单位的键值对（如"sm": 40em），仅用min-width实现向上覆盖，@content需大括号调用才能注入内容。
直接用 @mixin respond-to($name) 配合 $breakpoints map 是最稳、最易维护的方案，硬写 @media (min-width: 768px) 会把断点散落在各处，改一次就要全局搜索替换，漏一处就错位。
为什么必须用 map 而不是变量或 list
SCSS 的 map-get() 只认 map 类型。你写 $sm: 40em，调用 @include respond-to("sm") 就返回 null；写 (576px, 768px) 这种 list，@include respond-to("md") 直接失效。IDE 也无法跳转到定义处，协作时没人知道 $md 对应哪一层设备。
必须声明为键值对形式：
@use "sass:map"; $breakpoints: ( "sm": 40em, "md": 48em, "lg": 64em, "xl": 80em );
- 键名用
"sm"不用"mobile"：语义稳定，不绑定具体设备 - 值必须带单位：
40em，不能写40，否则编译报Invalid null operation - 单位优先选
em：适配缩放和动态根字号，px在高 DPI 设备或用户缩放时会失效
@mixin respond-to 里只用 min-width 的原因
用 @media (min-width: 48em) 天然支持“向上覆盖”，边界清晰。混用 max-width 容易触发重叠或遗漏——比如同时写 @media (max-width: 47.98em) 和 @media (max-width: 63.98em)，48–64em 区间两个都匹配，浏览器取后声明的规则，但你本意可能是让这个区间单独生效。
立即学习“前端免费学习笔记（深入）”；
- 所有断点按升序排列：
sm → md → lg → xl - 桌面端样式写在默认层（无媒体查询），移动端覆盖逻辑全交给
@include respond-to("sm")往上叠加 - 别在 mixin 内部写
max-width查询——它和min-width混用极易出问题
@content 调用时最容易踩的三个坑
@content 是内容块注入机制，不是函数返回值，对调用语法极其敏感：
- ✅ 正确：
@include respond-to("sm") { color: red; } - ❌ 错误：
@include respond-to("sm"); color: red;（@content为空） - ❌ 嵌套失效：
@include respond-to("sm") { @include hover-state { ... } }——若hover-state内部也用了@content，外层媒体查询结构会丢失 -
@content块内不能访问调用作用域的局部变量（这是 SCSS 作用域隔离规则，不是 bug）
断点变更时配套项必须同步更新
断点值变了，但容器宽度、栅格列宽、字体响应比例等配套变量没同步，会导致视觉错位。比如 $breakpoints 里 "md" 改成 52em，但 $container-md 还是 720px，那在中屏下容器可能溢出或留白异常。
真正可落地的响应式封装，从来不只是一个 mixin，而是 $breakpoints + @mixin respond-to + 同名配套变量（如 $container-sm）三者严格对齐的一套契约。漏掉任何一环，后期维护成本都会指数级上升。
