应使用Guard匹配断点名称（如sm、md），通过extract(@breakpoints, sm)获取对应像素值并注入min-width媒体查询，避免字符串比较失效；旧版Less需手动展开或升级支持。
Less Guard怎么写才能匹配断点名称而不是像素值
直接用 @media 套 .mixin 不算真正用上 Guard，关键在让 mixin 接收断点名（比如 sm、lg），再由 Guard 判断并注入对应 min-width。否则每次调用都要手写像素值，失去语义化优势。
正确做法是定义统一断点变量 + 带 Guard 的响应式 mixin：
@breakpoints: {
sm: 576px;
md: 768px;
lg: 992px;
xl: 1200px;
};
<p>.responsive(@size) when (@size = sm) {
@media (min-width: extract(@breakpoints, sm)) { .-content(); }
}
.responsive(@size) when (@size = md) {
@media (min-width: extract(@breakpoints, md)) { .-content(); }
}
.responsive(@size) when (@size = lg) {
@media (min-width: extract(@breakpoints, lg)) { .-content(); }
}注意：extract() 是 Less 3.5+ 才支持的函数，旧版本得手动展开或改用 map-get（需 Less 4.0+）。
Guard里用像素值比较会失效吗
会。Less Guard 中的数值比较默认按字符串处理，when (@width > 768px) 实际比的是字符串 "768px" > "768px"，永远为 false。必须先转成纯数字。
立即学习“前端免费学习笔记（深入）”；
- 用
unit(@val, px)提取数值：比如unit(768px, px)→768 - 或用
replace(@val, 'px', '') * 1强制转数字 - 但更稳妥的是——别在 Guard 里做像素计算，把断点逻辑抽到变量或函数里
例如下面这个常见错误写法：
.col(@width) when (@width > 768px) { width: @width; } // ❌ 永远不生效应改为：
.col(@width) when (unit(@width, px) > 768) { width: @width; } // ✅多个断点叠加时Guard怎么避免重复编译
Less 不会自动合并相同媒体查询，.responsive(sm) 和 .responsive(md) 各自生成独立 @media 块，哪怕它们最终都落在 min-width: 768px 下。这会导致 CSS 体积膨胀、维护困难。
解决思路不是靠 Guard 多条件判断，而是用嵌套 + 作用域控制：
.responsive-all() {
@media (min-width: extract(@breakpoints, sm)) {
&.sm { .-content(); }
}
@media (min-width: extract(@breakpoints, md)) {
&.md { .-content(); }
}
}这样所有断点规则集中在一个 mixin 内，调用一次就生成全部媒体查询，且可复用选择器结构。
为什么用Guard实现断点比纯CSS变量更可控
CSS 自定义属性无法参与媒体查询条件判断，也不能在编译期做逻辑分支。而 Less Guard 是编译时执行的，能真正实现「根据参数决定是否输出某段 CSS」。
典型场景：
- 只在
lg及以上启用 flex 布局，小屏回退为 block —— Guard 可精确控制生成哪套规则 - 某个组件在
sm断点下隐藏，但md开始显示，且lg加额外 padding —— 多个 Guard 分支天然适配 - 需要和 JS 运行时断点对齐？那就别用 Guard，换 CSS @container 或 JS 注入类名 —— Guard 纯属编译期工具，别越界
真正容易被忽略的是：Guard 不解决“运行时响应”，它只是帮你把不同断点的样式提前分好组。如果页面要动态响应窗口 resize，还得靠媒体查询本身或 JS 配合。
