<p>用 CSS @keyframes 配合 animation-delay 和 animation-fill-mode: forwards 实现列表项逐个高亮扫描，延迟用 calc(var(--index) * 50ms) 确保兼容性，禁用 transition 避免冲突，深色模式需重置背景色。</p>
怎么用 CSS 实现列表项逐个高亮扫描效果
直接用 @keyframes 配合 animation-delay 控制每个 li 的动画起始时间，别试图用 JS 控制 class 切换——CSS 原生就能做，更轻、更稳、不卡顿。
核心思路是：给每个 li 设置相同的动画（比如背景色从透明到浅黄），但通过 animation-delay 错开触发时机。延迟值用 CSS 自定义属性或预设的数值序列生成最稳妥。
- 避免用
:nth-child(n)硬写 20 条规则——维护成本高，且无法适配动态增删的列表 - 如果列表项数量不确定，优先用 JS 注入
style标签动态设置--delay变量，再在 CSS 中引用 - 动画时长建议控制在
0.3s ~ 0.5s，太短看不清，太长像加载卡顿
为什么 animation-fill-mode: forwards 必须加
不加的话，高亮只闪一下就回退到原始样式，根本留不住“扫描到当前位置”的视觉状态。尤其当用户滚动暂停时，需要明确看到当前焦点在哪。
forwards 让动画最后一帧的样式（比如 background-color: #fff9c4）持续生效，而不是恢复初始值。这是实现“扫描停驻”感的关键一环。
立即学习“前端免费学习笔记（深入）”；
- 漏掉这个声明，动画看起来就是“划过即逝”，失去引导意义
- 和
animation-direction: normal搭配使用最安全；避免用alternate，容易导致偶数项颜色异常 - 如果高亮需要支持深色模式，记得在
@media (prefers-color-scheme: dark)里重置背景色值
transition 和 animation 混用会出什么问题
千万别在一个 li 上同时写 transition: background-color 和 animation 改同一属性——浏览器行为不可控，常见表现是高亮闪烁、跳帧、甚至完全不触发动画。
CSS 动画和过渡在属性冲突时，动画优先级更高，但过渡的“中间态”残留可能干扰关键帧计算，尤其在快速滚动或低性能设备上。
- 统一用
animation处理扫描高亮，彻底禁用相关属性的transition - 如果列表本身有 hover 效果，确保 hover 的
background-color不和扫描动画冲突，可用!important或更高特异性的选择器覆盖 - 测试时打开 Chrome DevTools 的 Rendering 面板，勾选 “Paint flashing”，确认只有预期区域重绘
移动端 Safari 对 animation-delay 的兼容性坑
iOS 15.4 之前版本对小数秒级的 animation-delay（如 0.05s）支持不稳定，可能导致部分 li 完全不启动动画，或延迟严重错位。
实测可靠方案是：把延迟单位放大 10 倍，用整数毫秒（50ms）代替小数秒（0.05s），并显式声明 animation-timing-function: linear 避免默认缓动干扰节奏。
- 写成
animation-delay: calc(var(--index) * 50ms)比calc(var(--index) * 0.05s)更稳 - 不要依赖
will-change: transform强制 GPU 加速——在旧版 Safari 上反而引发渲染撕裂 - 真机测试必做，模拟器容易掩盖 timing bug
实际效果是否自然，取决于延迟步长是否匹配人眼识别节奏。太快像乱闪，太慢像卡顿。0.15s 间隔多数场景下最耐看——但这不是参数，是观察结果。
