.flex-row()比手写display: flex更可靠，因其在编译期固化合法组合、拼写错误直接报错，并将“横向布局+主轴左对齐+侧轴拉伸”封装为不可拆分单元。
为什么.flex-row()比手写display: flex更可靠
手写容易漏掉align-items或把justify-content: center错打成justfy-content，而.flex-row()这类Mixin在编译期就固化了合法组合，拼写错误直接报错。它不只省键盘，关键是把“横向布局+主轴左对齐+侧轴拉伸”这个意图打包成一个不可拆分的单元。
常见错误是把所有属性塞进一个.flex()无参Mixin，结果遇到垂直布局还得覆盖flex-direction，反而增加维护成本。正确做法是按高频意图命名：
-
.flex-row()→display: flex; flex-direction: row; justify-content: flex-start; align-items: stretch; -
.flex-col-center()→flex-direction: column; justify-content: center; align-items: center; -
.flex-between()→ 只改justify-content: space-between，其他继承父级或默认值
如何避免flex-wrap被意外覆盖
flex-wrap: wrap不是容器的默认行为，但90%的卡片列表需要它，导航栏却必须nowrap。如果把wrap硬写死在.flex-row()里，调用方就丧失控制权。
实操建议是拆出独立的wrap变体：
立即学习“前端免费学习笔记（深入）”；
-
.flex-row-wrap()内部先调用.flex-row()，再追加flex-wrap: wrap; - 项目级子项用
.flex-1()、.self-end()等独立Mixin控制，和容器解耦——改align-self不用动父容器声明 - 不要在Mixin里用
when (@wrap = true)这种布尔参数，而是用显式命名：有wrap就带wrap，没写就不生效，语义更直白
响应式断点必须作为参数传入，不能硬编码媒体查询
典型翻车是这样写：@media (max-width: 768px) { .header { flex-direction: column; } }——PC和移动端逻辑割裂，后期改justify-content得同步改两处。
正确路径是把断点变成可选参数，并用变量统一管理：
- 定义变量：
@bp-md: 768px; - Mixin签名：
.flex-stack(@breakpoint: md) - 内部实现：
@media (max-width: @bp-@{breakpoint}) { .flex-col(); }（注意@bp-前缀拼接） - 调用时写
.flex-stack(md)，既语义清晰，又支持全局调整@bp-md值
别在Mixin里直接写@media (max-width: 768px)，否则无法被外层媒体查询包裹（比如整个模块要统一禁用移动端堆叠）。
为什么不用CSS自定义属性替代这些Mixin
CSS变量适合控制颜色、间距这类标量，但justify-content和align-items的合法值之间有强约束关系。例如space-between配stretch会导致子项高度塌缩，而center配flex-start才合理。
Mixin能在编译期屏蔽非法组合：
- 用
when守卫限制参数范围：.flex-justify(@j) when (@j = flex-start), (@j = center), (@j = space-between) - 如果传入
.flex-justify(top)，Less编译直接报错，而不是生成无效CSS - 而CSS变量
--justify: top会被浏览器静默忽略，问题拖到运行时才发现
真正难处理的是动态计算场景，比如根据子元素数量自动设flex-basis——这只能靠Less函数，CSS变量完全无能为力。
