使用 $breakpoints map 管理断点最可靠，@mixin respond-to($breakpoint) 封装调用，键名如 "sm" 语义稳定且必须带单位；仅用 min-width 避免覆盖冲突；@content 必须大括号包裹；容器宽度等需与断点 map 同名键同步更新。
直接用 @mixin respond-to($breakpoint) 封装断点，配合 $breakpoints map 定义，是最省事、最不易出错的方式。硬编码 @media (min-width: 768px) 看似快，改一次断点就要全局搜替换，漏一处就导致布局错乱。
为什么必须用 map 而不是变量或 list
SCSS 的 map-get($breakpoints, $breakpoint) 只接受 map 类型；传入 list（如 (576px, 768px)）会返回 null，@include respond-to("md") 直接失效。单个变量（如 $md: 768px）无法按名查值，IDE 不能跳转，协作时没人知道 $md 对应哪一层设备。
正确写法：
@breakpoints: ("sm": 576px, "md": 768px, "lg": 992px, "xl": 1200px);
- 键名用
"sm"不用"mobile"：语义稳定，“sm” 指小尺寸断点，不绑定具体设备 - 值必须带单位：
576px，不能写576，否则编译报Invalid null operation - 调用时传字符串：
@include respond-to("md")✅，不是@include respond-to(md)❌
@mixin respond-to 里只用 min-width 的原因
用 min-width 天然支持向上覆盖，边界清晰。写 @media (max-width: 767px) 和 @media (max-width: 1023px) 会导致 768–1023px 区间两个都匹配，浏览器取后者——但你可能只想让这个区间单独生效，这时就得加 and (min-width: 768px)，反而更啰嗦。
实操建议：
- 所有断点按升序排列：
sm → md → lg → xl，CSS 后声明的规则自然覆盖前序 - 桌面端样式写在默认层（无媒体查询），移动端覆盖逻辑全交给
@include respond-to("sm")往上叠加 - 别在
@mixin内部写max-width查询——它和min-width混用极易触发重叠或遗漏
@content 调用时最容易踩的三个坑
@content 是“内容块注入”，不是函数返回值，对上下文敏感。写了却没生效，大概率是调用姿势不对。
- 必须用大括号包裹内容块：
@include respond-to("md") { color: red; }✅；写成@include respond-to("md"); color: red;❌（后者@content为空） - 不能在
@content块里再嵌套另一个带@content的@mixin，会丢上下文，比如respond-to里调hover-state，结果外层 media 规则丢失 -
@include必须写在 CSS 规则块内部（即有选择器后的大括号里），不能直接写在顶层或变量声明后，否则不产出任何 CSS
断点和容器宽度脱节怎么办
断点变了，但 .container 最大宽度没同步更新，页面就会在某个宽度下突然撑破或留白异常。这不是媒体查询的问题，而是布局系统没对齐。
例如你把 "lg" 从 992px 改成 1024px，那 $container-max-widths 里的 "lg" 也得同步改，否则 .container 在 1000px 宽度下仍按 992px 计算，内容区就溢出了。
建议：
- 容器宽度变量也用 map 管理，和断点 map 同名键对齐，比如
$container-max-widths: ("sm": 540px, "md": 720px, "lg": 960px, "xl": 1140px) - 所有断点相关值（导航折叠临界点、栅格列宽、字体缩放阈值）都从同一份
$breakpoints衍生，避免手动计算偏差
真正难的不是写对第一个 @mixin，而是后续所有人改断点时，是否都记得去同步容器、栅格、JS 判断逻辑——这些地方不联动，响应式就只是看起来在动。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
