Less如何实现CSS加载进度条：通过Mixin处理颜色变化
Less里没法直接监听CSS加载进度
这里有个常见的误解需要先澄清：CSS本身是一种声明式资源，浏览器压根儿不提供加载进度事件。而Less作为预处理器，它的工作早在代码运行前就结束了，自然更不参与运行时加载。所以，我们常说的“CSS加载进度条”，本质上是一种前端障眼法——用Ja vaScript模拟出来的视觉反馈。那么Less的价值在哪里呢？它负责把进度条背后那套颜色过渡的逻辑，写得既专业又易于维护。重点就在于，如何巧妙地运用Mixin来管理渐变色和状态色。
用.progress-colors() Mixin统一管理进度阶段色值
直接在样式里硬编码多个background-color，或者写一堆零散的@keyframes，代码很快就会变得难以维护。一个更优雅的解决方案是：用Mixin把颜色映射关系抽离出来。这样做的好处显而易见，既方便未来做主题切换，也彻底避免了重复计算。
- 让Mixin接受一个基础颜色变量（比如
@primary），再加上一个可选的明度偏移参数，让它自动为你生成起始色、中间色和完成色。 - 内部使用
lighten()和darken()这类函数进行计算，而不是写死HEX值。这样才能确保在深色模式下，颜色过渡依然协调自然。 - 记住Mixin的职责边界：它只负责输出色值。像
transition这类与动画相关的属性，应该留给组件层去控制，别在Mixin里越俎代庖。
.progress-colors(@color, @offset: 15%) {
--progress-start: lighten(@color, @offset);
--progress-mid: @color;
--progress-end: darken(@color, @offset);
}
配合data-loaded属性做状态驱动，别依赖@import顺序
另一个容易踩的坑是试图用@import的顺序来控制样式生效的时机。这行不通，因为Less编译之后，所有的CSS都已经合并成一个文件了，根本无法反映真实的加载节奏。真正可控的，其实是Ja vaScript触发的DOM状态。
- 正确的做法是，在Ja vaScript确认关键CSS加载完毕后，给
这类根元素加上一个像data-loaded="true"这样的属性。 - 然后，在Less中，用属性选择器配合Mixin生成的CSS变量，来实现样式的状态响应。
- 这里有个关键细节：不要把
[data-loaded="true"]这样的选择器直接写在Mixin内部，这会严重污染Mixin的复用性。应该把它留在调用Mixin的具体上下文中。
.loader-bar {
background: var(--progress-start);
transition: background 0.3s ease;
}
[data-loaded="true"] .loader-bar {
background: var(--progress-end);
}
IE11下var()不支持，得备选方案
如果你的项目还需要照顾到IE11这位“老前辈”，那么基于CSS变量的方案就得打个问号了。这时候，我们必须准备一套回退方案，通常就是回退到传统的类名切换模式。这意味着我们的Mixin需要变得更聪明一点，能够支持双输出模式：默认情况下生成CSS变量版本，而当传入特定参数时，则输出兼容IE的类名版本。
立即学习“前端免费学习笔记（深入）”；
- 用
@support规则包裹住CSS变量的逻辑，这样IE会自动跳过这部分，执行备选方案。 - 在Mixin内部，可以使用
.when()这类条件判断，来决定是否启用类名模式，从而避免生成冗余的代码。 - 还有一个容易忽略的点：
transition属性在IE11里只认-ms-前缀。不过别担心，Less内置的.transition()等函数通常已经帮我们处理好了这些兼容性问题。
整个方案最复杂的地方，其实在于状态同步。Ja vaScript必须同时操作data-属性和class类名，否则视觉样式和程序逻辑就会脱节。这个衔接点，往往是最容易在测试中被遗漏的环节。
