编写CSS媒体查询本身并不复杂，但要在真实项目中高效维护，却常常让人头疼。你可能认为只需掌握 min-width 和 max-width 即可，但随着项目规模增长，成百上千个 @media 散落在各个组件文件中，修改一个断点值就需要搜索整个代码库——一旦遗漏一处，iPad 上的按钮布局就会错位；更麻烦的是，max-width 的边界条件常被忽略，导致断点之间出现重叠或间隙，样式意外继承。问题的根源并非语法难记，而是缺乏统一的配置入口和语义化的封装机制。像素值到处硬编码、断点逻辑与业务代码紧密耦合、缺少校验手段，使得响应式开发沦为“猜着修”的体力劳动。
为什么直接使用 @media 查询容易失控
修改一个断点值需要搜索整个项目，因为 @media (min-width: 768px) 分散在组件、工具类、布局文件中，漏改一处就会导致平板设备上按钮错位；更糟糕的是，max-width 边界常被忽略，造成断点重叠或空白——例如 tablet 和 desktop 之间没有定义 and (max-width: 989px)，样式就会意外继承。根本问题并非语法复杂，而是缺少统一入口和语义封装。像素值散落各处、逻辑耦合、无校验机制，使得响应式设计变成“猜着修”的体力活。
mq() mixin 需支持三种模式：min、max 与 between
只支持单参数的 mq($breakpoint) 在真实项目中很快撞墙。你需要明确表达“从某点开始”“到某点为止”“在两点之间”这三类行为。
@include mq(sm)→@media (min-width: 576px)@include mq(max: md)→@media (max-width: 767px)（注意使用-1px避免边界冲突）@include mq(sm, lg)→@media (min-width: 576px) and (max-width: 1199px)
关键细节：between 模式必须用 max-width: $value - 1px，否则两个相邻断点会同时生效；$breakpoints 里建议不写单位（如 sm: 576），让 mixin 统一添加 px 或转换为 em，避免混用。
断点命名应具备语义，避免硬编码像素值
别用 768、1024 这类数字命名变量。实际项目中，tablet 不等于 “768px”，它代表“横向握持的平板设备交互临界点”，这个值可能因设计系统调整为 812px 或 740px。
推荐写法：
$breakpoints: ( xs: 0, sm: 576, md: 768, lg: 992, xl: 1200 );
所有像素值只出现在 $breakpoints 里，业务层只认名字。新增 retina 或 dark-mode 这类非尺寸断点时，也走同一套 map 结构，不额外写 @media 块。
务必添加 @if map.has-key() 校验与错误提示
写 @include mq(phone) 却忘了在 $breakpoints 里定义 phone？没有校验时 Sass 编译直接报错，但错误信息指向 mixin 内部，定位困难。
正确做法是在 mixin 开头加：
@if not map.has-key($breakpoints, $breakpoint) {
@error "Unknown breakpoint `#{$breakpoint}`. A vailable: #{map.keys($breakpoints)}";
}
这样调用出错时，终端立刻告诉你可用的断点名，而不是翻 config 文件猜拼写。
真正容易被忽略的并非语法本身，而是将断点视作配置项来管理——它应当可查询、可报错、可复用，而非一段写死的字符串。
