纯CSS无法生成随机或位置响应的颜色，必须依赖JS计算后写入CSS变量，再由hsl()、color-mix()或oklch()消费；JS需映射鼠标位置为0–1比例并节流，CSS用calc()绑定变量，注意单位、范围、兼容性及格式规范。
纯 CSS 无法真正“生成”随机或位置响应的颜色，所有动态颜色都依赖 JS 计算后写入 --var，再由 CSS 用 hsl()、color-mix() 或 oklch() 消费——这是当前最可靠、可维护的路径。
用 JS + hsl() 实现鼠标位置驱动的颜色变化
核心是把 clientX/clientY 映射为 0–1 比例值，再转成 HSL 参数。别用 pageX/pageY，它们随滚动跳变；更稳妥的是 event.clientX / window.innerWidth（注意：横向滚动时应改用 document.documentElement.scrollWidth）。
- 必须加节流：
setTimeout控制在 ~16ms（60fps），否则高频触发拖慢渲染 - 移动端要监听
touchmove并取touches[0].clientX -
document.documentElement.style.setProperty('--mouse-x', (e.clientX / window.innerWidth).toString())—— 值必须是字符串 - CSS 中写成
background: hsl(calc(var(--mouse-x) * 360), 70%, calc(40% + var(--mouse-y) * 40%))，注意单位和范围限制（亮度避开0%和100%） - 务必监听
mouseleave重置变量，否则移出窗口后颜色会“冻结”
用 color-mix() 做颜色插值，但得处理兼容性
color-mix() 是唯一原生支持按权重混合两种颜色的函数，写法直观：color-mix(in srgb, red 70%, blue 30%)。但它不接受变量、currentcolor 或计算表达式，只能塞具体颜色值。
- 权重加起来不必等于
100%，浏览器会自动归一化（red 2, blue 1等价于red 66.6%, blue 33.3%） - 必须显式指定色彩空间：
in srgb最稳；in lch更符合人眼，但 Safari 不支持 - Safari 当前不支持
color-mix()，降级方案只能 fallback 到hsl()或 JS 预计算 - 别指望它和
var(--primary)联动——变量需提前 resolve 成具体值（比如构建时 PostCSS 处理），运行时不可用
用 from + calc() 衍生调色板，空格和斜杠不能错
rgb(from #3b82f6 r g b) 本身不生成新色，只是复读；真正起作用的是 calc() 对通道的运算，比如 hsl(from var(--primary) h s calc(l - 12)) 才能变暗。
立即学习“前端免费学习笔记（深入）”；
- alpha 必须用
/引入：rgb(from #000 r g b / 0.6)✅，rgb(from #000 r g b, 0.6)❌ - HSL 的
l是 0–100 数值，不带%；oklch()的L是 0–1 小数，单位敏感 - 用
@supports (color: oklch(0 0 0))包裹oklch()代码，避免 Safari 直接忽略整条声明 -
calc(l - 30)可能算出负数，浏览器会 clamp，结果不可控；建议加边界判断或用max(12, calc(l - 12))
JS 生成随机色时，别只调 --h 忘了 --s 和 --l
常见翻车：JS 只更新 --h，CSS 却写 hsl(var(--h), 70%, 60%)，导致饱和度/亮度固定，随机出来的色不是灰就是发白。
- 每次生成需同步设三个变量：
--h（0–360）、--s（60–100）、--l（40–70），避开极端值 -
:root里必须预设 fallback：--h: 204; --s: 68%; --l: 53%;，否则 SSR 或 JS 加载前背景透明 - 过渡动画必须写在目标元素上：
transition: background-color 0.15s ease；仅靠变量变化不会触发重绘 - 多个元素共用同一套变量时，点击切换主题只需改一次
:root，比遍历element.style.backgroundColor可维护得多
真正容易被忽略的是：所有这些函数对格式极其敏感，一个空格、少一个 /、单位写错，整条声明就被浏览器静默丢弃——调试时优先检查控制台是否报 Invalid property value，而不是怀疑逻辑。
