Less中需用Mixin封装带参数的媒体查询，参数为断点键名而非字符串，通过map-get从@breakpoints映射取值，并加isdefined守卫；硬编码断点导致维护难、嵌套失效、单位混用；多条件查询需用@media(@conditions...)配合~"@{conditions}"拼接；应区分.media-up()与.media-down()以适配移动端或桌面端优先策略。
Less里怎么写带参数的媒体查询Mixin
直接用@media套.media()这种写法行不通——Less不认原生CSS规则当函数。必须用Mixin封装，且参数得是断点值本身，不是字符串。
常见错误是把断点写成.media("md")，结果编译报错Expected variable, function or keyword，因为Less无法在运行时解析字符串为数值。
- 断点变量统一定义在
@breakpointsmap里，比如@breakpoints: { xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px }; - Mixin用
.media(@size)接收键名，内部用map-get(@breakpoints, @size)取值 - 别漏掉
when (isdefined(@breakpoints))守卫，否则没定义断点时会静默失败
.media(@size) when (isdefined(@breakpoints)) {
@value: map-get(@breakpoints, @size);
@media (min-width: @value) {
@content();
}
}为什么不能直接用@media (min-width: @sm)硬编码
看着省事，但维护成本高：每次改断点要搜遍所有文件；多人协作时容易漏改；还可能误用@sm当像素值参与计算，导致单位混用（比如@sm * 2变成768px * 2，结果是1536px px这种非法值）。
更隐蔽的问题是嵌套失效：@media (min-width: @sm) { .box { width: 100%; @media (max-width: @sm - 1px) { display: none; } } }——第二层@media不会被Less识别为嵌套规则，直接原样输出到CSS里。
立即学习“前端免费学习笔记（深入）”；
- 硬编码断点让响应式逻辑散落在各处，没法集中管理
- Less的
@media嵌套只认顶层@media声明，子级必须用Mixin或&语法 - 单位不一致时，
px和em混用会导致计算结果不可预期
如何支持多条件媒体查询（比如横屏+最小宽度）
单参数Mixin应付不了@media (min-width: 768px) and (orientation: landscape)这种组合。得扩展Mixin支持可变参数列表。
典型错误是试图用.media(@a, @b)硬写两个参数，结果调用时顺序一乱就错；或者用字符串拼接，失去类型检查和编译时校验。
- 用
.media(@conditions...)接收参数列表，再用each()遍历生成条件 - 每个条件单独封装为变量，比如
@min-width: 768px、@orientation: landscape，避免字符串拼接 - 注意
and连接符不能靠空格自动补全，必须显式写进@conditions里，比如.media("min-width: 768px", "and", "orientation: landscape")
.media(@conditions...) {
@query: ~"@{conditions}";
@media @{query} {
@content();
}
}移动端优先还是桌面端优先影响Mixin设计
Less本身不区分优先级，但你的Mixin命名和默认行为会暴露倾向。比如叫.up(@size)暗示向上扩展（移动端优先），叫.down(@size)则暗示向下收缩（桌面端优先）。
最容易被忽略的是max-width断点的边界问题：用@media (max-width: 767.98px)比767px更安全，避免1px间隙导致样式未命中。但Less不支持浮点运算，得手动写767.98px或用floor(@md - 0.02px)（需math库）。
- 移动端优先方案通常用
min-width，覆盖范围大，适合渐进增强 - 桌面端优先方案依赖
max-width，但不同设备DPR可能导致像素对齐偏差 - 如果项目同时存在两种策略，Mixin必须能区分，比如
.media-up()和.media-down()分开定义
实际用的时候，断点值的精度、单位一致性、以及map-get查不到键时的fallback处理，比语法本身更容易出问题。
