必须用 map 而非 list 或变量，因 map-get 要求 map 类型才能按名查值；list 无法通过键名（如 "md"）获取断点，单变量无法批量管理、IDE 不支持跳转、协作语义不清。
直接用 @mixin respond-to($breakpoint) 封装断点，配合 map 定义语义化键值对，是最稳、最易维护的方案。硬编码 @media (min-width: 768px) 是后期改断点时最耗时间的坑。
为什么必须用 map 而不是 list 或变量？
SCSS 的 map-get($breakpoints, $breakpoint) 要求 $breakpoints 是 map 类型，否则编译报错或返回 null。list（如 (576px, 768px)）没法按名字查值，@include respond-to(md) 就失效；单个变量（如 $md: 768px）则无法批量管理、IDE 不能跳转、协作时没人知道 $md 到底对应哪一层设备。
正确写法：
$breakpoints: (
"sm": 576px,
"md": 768px,
"lg": 992px,
"xl": 1200px
);
@mixin respond-to($breakpoint) {
@if map-has-key($breakpoints, $breakpoint) {
@media (min-width: map-get($breakpoints, $breakpoint)) {
@content;
}
}
}
- 键名用
"sm"不用"mobile"：语义稳定，“sm” 指“小尺寸断点”，不绑定具体设备 - 值带单位（
576px），别写576——SCSS 会报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混用极易触发重叠或遗漏
怎么避免断点和容器宽度脱节？
断点变了，但 .container 最大宽度没同步更新，页面就会在某个宽度下突然撑破或留白异常。这不是媒体查询的问题，而是布局系统没对齐。
例如你把 "lg" 从 992px 改成 1024px，那 @container-max-widths 里的 "lg" 也得同步改，否则 .container 在 1000px 宽度下仍按 992px 计算，内容区就溢出了。
- 容器宽度变量也建议用 map 管理，和断点 map 同名键对齐
- 不要手写
max-width: 992px——统一用map-get($container-max-widths, "lg") - 如果用 Webpack + less-loader，确认
modifyVars没覆盖你自定义的断点变量，否则编译后全是@media (min-width: 0)
调试时最常忽略的一点
DevTools 里禁用某个 @media 块，看到样式没变，第一反应是“断点没生效”，其实更可能是：你用了 max-width 导致区间重叠，或者 @content 里写的样式被更高优先级的选择器覆盖了。真正该盯的是「当前宽度下，哪些媒体查询被命中」+「对应块里有没有定义你要改的那个属性」。
用 min-width + 升序书写后，打开 DevTools 的「Rendering」面板，勾选「Emulate CSS media features」，拖动宽度滑块，能清晰看到每个断点的触发边界——这是验证是否真“响应”的最快方式。
