应使用语义化 Sass Map $breakpoints 统一管理响应式断点，配合 breakpoint-up() 等混合宏封装媒体查询，避免硬编码、单位丢失和边界错误，并通过构建脚本将断点同步至 JS 运行时。
用 $breakpoints Map 存响应式断点，别手写一堆 @media
直接把断点定义成 Sass Map，后续所有媒体查询都从它读，改一处全更新。不是为了炫技，是避免 768px、1024px 在不同文件里散落、不一致、漏改。
常见错误：用变量链式定义（$sm: 576px; $md: $sm * 1.78;），数值失去语义，后期调整比例时反而更难算准。
-
$breakpoints必须是 key-value 对，key 是语义名（如sm、lg），value 是带单位的长度值（576px或36em） - 推荐用
em单位，适配根字体缩放，比px更健壮 - Map 本身要声明在全局作用域（如
_variables.scss），且早于任何用到它的模块被引入
写 breakpoint-up() 和 breakpoint-down() 混合宏时，必须用 map-get() 取值
手动拼 @media (min-width: #{$sm}) 是倒退。混合宏封装后，调用才干净，也方便统一加逻辑（比如自动补 1px 避免边界重叠）。
典型坑：传入的断点名不存在，map-get($breakpoints, $name) 返回 null，Sass 编译直接报错 "null is not a valid CSS value"。
立即学习“前端免费学习笔记（深入）”；
- 务必在混合宏开头加守卫：
@if not map-has-key($breakpoints, $name) { @error "Unknown breakpoint: #{$name}"; } - 不要在混合宏里硬编码单位转换，Sass 3.4+ 支持直接比较带单位的值，
map-get($breakpoints, sm) >= 1em是合法的 - 如果项目需兼容 IE，
max-width断点建议用breakpoint-down(lg)而非breakpoint-up(md)，避免区间缝隙
用 breakpoint-inclusive() 处理“等于”场景时，map-get() 结果必须参与计算，不能当字符串拼
有些设计稿明确要求“在 lg 断点下生效”，即 @media (min-width: 992px) and (max-width: 1199.98px) 这种闭区间。这时不能把 map-get($breakpoints, lg) 当字符串塞进 #{} 插值里——单位会丢，或变成非法 CSS。
错误示例：@media (min-width: #{map-get($breakpoints, lg)}) → 输出 (min-width: 992)，缺 px。
- 正确做法：用 Sass 内置函数做单位运算，例如
$val: map-get($breakpoints, lg); @media (min-width: $val) and (max-width: $val + 0.98px) - 若断点用
em，加0.98px会报单位不匹配错误，此时应换算：$val + 0.98px / 16（假设 base font-size=16px） - 更稳妥的是预存“上限值”在 Map 里：
lg: (min: 62em, max: 74.99em)，但会增加维护成本
导出断点给 JS 用时，json-export 类库无法处理 Sass Map，得靠构建脚本中转
前端有时要在 JS 里判断当前断点（比如懒加载组件逻辑），指望 Sass 编译后吐出 JSON 不现实——Sass 本身不输出运行时数据。
常见翻车：写个 @function to-json($map) { ... }，以为能生成 JSON 字符串，结果编译后还是 Sass 语法，JS 拿不到。
- 真正可行的是在构建流程里（如 Webpack 的
loader或 Vite 插件），读取_variables.scss文件，用正则或 AST 解析出$breakpoints定义，再写入breakpoints.json - 如果用 Dart Sass，可借助其 JavaScript API，在构建脚本里调用
sass.compileString()并注入自定义函数，把 Map 转成 JSON 字符串输出到文件 - 切记 JS 端读到的断点值是字符串（
"576px"），需要用parseFloat()或match()提取数字，再配合window.matchMedia()使用
Map 看似简单，但跨语言同步、单位一致性、边界计算这三块，漏掉任一细节都会让响应式逻辑在某类设备上悄悄失效。
