应使用 SCSS Map 定义语义化断点，如 $breakpoints: (sm: 768px, md: 1024px, lg: 1280px, xl: 1440px)，配合 @mixin res($key) 封装媒体查询逻辑，实现可查、可复用、可组合的断点管理，避免硬编码和设备词变量。
直接用硬编码的 @media (min-width: 768px) 写断点，改一次要全局搜索替换，漏一处就导致布局错乱——这不是响应式，是“响应雷”。真正可控的方式，是把断点变成可查、可复用、可组合的数据结构。
如何用 SCSS Map 定义语义化断点
别再写 $breakpoint-mobile: 480px 这种带设备词的变量。设备尺寸每年变，但内容容器“开始撑不开”的宽度是稳定的。用 Map 把断点组织成键值对，语义清晰且便于遍历：
@mixin res($key) {
@if map-has-key($breakpoints, $key) {
@media (min-width: map-get($breakpoints, $key)) {
@content;
}
}
}
<p>$breakpoints: (
sm: 768px,
md: 1024px,
lg: 1280px,
xl: 1440px
);这样写的好处是：map-get($breakpoints, sm) 可被其他 mixin 复用，也能配合 @each 批量生成工具类（比如 .d-sm-none）；更重要的是，新增断点只需往 Map 里加一行，不碰逻辑。
为什么不能直接在 @media 里用 var(--sm)
CSS 变量不能出现在 @media 条件中，浏览器会直接忽略整条规则。你可能会看到这样的错误写法：
立即学习“前端免费学习笔记（深入）”；
@media (min-width: var(--sm)) { /* ❌ 无效，规则被丢弃 */ }这是纯 CSS 的硬限制，和 SCSS 无关。SCSS 编译阶段变量已展开，所以它不受影响；但如果你混用 JS 注入或 PostCSS 替换，就得确保构建流程能识别并提前替换 var(--sm) 成实际像素值。否则，调试时 DevTools 里根本看不到这条媒体查询生效。
如何避免 @extend 导致断点样式顺序错乱
在响应式场景下，@extend %btn-base 很危险：Sass 会把 %btn-base 的声明插到它第一次被 @extend 的位置，而不同组件可能在不同文件里引用它。结果就是：
-
.btn--primary在md断点下的padding被%btn-base后续插入的默认padding覆盖 - 你检查源码时发现规则顺序和你写的完全不一致
解决办法很明确：
- 禁用跨文件
@extend，同一文件内也只用于无响应逻辑的原子规则（如%visually-hidden） - 所有带断点的复用逻辑，一律改用
@include+ mixin，输出顺序完全可控 - 如果必须抽象共用样式，用
@mixin button-base()替代%btn-base
什么时候该用容器查询，而不是视口断点
当你发现某个卡片在桌面端宽屏下显示正常，但嵌进一个窄侧边栏里就文字溢出——这时视口断点已经失效。因为问题不在屏幕多宽，而在“这个容器本身多宽”。
现代方案是用 @container：
.card {
container-type: inline-size;
}
@container (min-width: 400px) {
.card__title { font-size: 1.25rem; }
}注意：@container 需要父元素显式设置 container-type，且目前 Safari 和 Chrome 支持良好，Firefox 已支持（截至 2026 年 4 月）。它不替代视口断点，而是补足其盲区——复杂响应式真正的难点，从来不是“怎么写断点”，而是“该在哪一层判断尺寸”。
