应优先使用Less内置fade()函数处理透明度，它自动适配HEX/RGB/RGBA/HSL输入并输出标准RGBA；避免手动解析颜色或误用transparentize()；Mixin需语义化封装，且CSS变量场景应分层处理而非强行兼容。
Less里直接用fade()就能算透明度，别自己写RGB转RGBA的函数
Less内置的fade()函数是处理透明度最稳妥的方式。它接收一个颜色值和一个不透明度百分比（0–100），自动适配HEX、RGB、RGBA甚至HSL输入，输出标准RGBA。自己解析HEX、拆分RGB、再拼字符串不仅冗余，还会在深色模式、CSS变量或渐变背景下失效。
常见错误是看到rgba(red, green, blue, alpha)就以为得手动提取数值——但Less不是JS，没有parseInt()或.split()，强行模拟只会让Mixin难以维护。
-
fade(#3498db, 70%)→rgba(52, 152, 219, 0.7) -
fade(rgb(255, 0, 100), 30%)→rgba(255, 0, 100, 0.3) -
fade(hsl(200, 100%, 50%), 50%)→rgba(0, 170, 255, 0.5)
用Mixin封装fade()时，只暴露语义化参数，别暴露底层计算逻辑
封装目标不是“实现透明度算法”，而是“快速生成带透明度的背景色”。所以Mixin参数应聚焦业务含义：主色、透明度强度、是否覆盖默认背景。不要加“base-color”“alpha-value”这类技术术语参数。
示例：.bg-fade(@color, @level: medium) { ... } 比 .bg-opacity(@c, @a) { ... } 更易读、更少出错。
立即学习“前端免费学习笔记（深入）”；
-
@level: light→fade(@color, 15%) -
@level: medium→fade(@color, 30%) -
@level: heavy→fade(@color, 60%)
这样调用时写.bg-fade(#e74c3c, heavy)就知道是“深红+较重遮罩”，而不是反复查文档确认0.6对应哪一档。
慎用transparentize()替代fade()——它减的是不透明度，不是加
transparentize(@color, @amount) 是把原色的alpha值“减少”@amount（0–1），常被误当成fade()的反向操作。比如transparentize(#000, 0.3)结果是rgba(0,0,0,0.7)，而非rgba(0,0,0,0.3)。想设为30%不透明，得写transparentize(#000, 0.7)，极易混淆。
除非明确需要“在已有透明色基础上再透一点”，否则一律用fade()。尤其在主题切换场景中，transparentize()对纯色输入的行为不可预测（如transparentize(hsl(0,0%,100%), 0.2)可能产出意外灰阶）。
背景透明Mixin必须兼容CSS变量，但Less无法直接操作var(--color)
如果项目已用CSS自定义属性传色（如--primary: #2980b9），Less的fade()无法直接处理var(--primary)——它会原样输出，浏览器报错Invalid property value。
此时不能硬改Mixin去“检测是否为var()”，而应分层处理：
- 设计系统级Less变量（
@primary: #2980b9）供Less编译期使用 - CSS变量仅用于运行时动态主题，其透明版本由JS或单独CSS规则控制（如
[data-theme="dark"] .card { background: rgba(41, 128, 185, 0.15); }） - 若真需运行时透明，放弃Less计算，改用
background: color-mix(in srgb, var(--primary), transparent 85%)（现代浏览器支持）
试图让LessMixin“智能识别并绕过CSS变量”只会引入is-color()判断、if()分支和fallback兜底，最终Mixin变成黑盒，谁都不敢动。
