Scroll-driven动画失效主因是环境不满足：@scroll-timeline须在顶层CSS定义、滚动容器需显式设置overflow、source:auto仅回退至根容器、动画元素须在同滚动容器内；Safari 17.5+才完整支持，旧版静默忽略；可用CSS.supports('animation-timeline: scroll()')检测并降级。
Scroll-driven 动画（@scroll-timeline + animation-timeline）在 Chrome/Edge 115+ 和 Safari 17.5+ 中已稳定支持，但一旦失效，基本不是写法错误，而是环境不满足或浏览器版本未达标。
为什么@scroll-timeline完全没反应
常见现象是动画静默不播、元素无任何位移或颜色变化，控制台也无报错。根本原因有三类：
-
@scroll-timeline规则必须定义在顶层 CSS（不能嵌套在@media、@supports或组件 scoped style 内），否则整个规则被忽略 - 滚动容器未显式设置
overflow: auto或overflow-y: scroll，导致浏览器无法识别其为有效滚动源；source: auto只回退到根滚动容器（document.scrollingElement），若页面靠scrollTop驱动而非自然滚动，它就不可用 - 动画绑定的元素不在该滚动容器内（例如时间线定义在
#list上，但动画元素在body下），animation-timeline不会跨容器生效
Chrome 正常但 Safari 17.4 及更早版本不执行
Safari 直到 17.5（对应 macOS Sonoma 14.5 / iOS 17.5）才完整支持@scroll-timeline语法，旧版会直接跳过整条规则——既不报错，也不降级，表现为“写了等于没写”。此时不能靠try/catch检测，得用特性判断：
if (!CSS.supports('animation-timeline: scroll()')) {
// 启用 JS fallback：监听 scroll + requestAnimationFrame 更新 transform
}注意：CSS.supports('scroll-timeline-name: foo')无效，必须用animation-timeline这个实际生效的属性来测。
立即学习“前端免费学习笔记（深入）”；
用IntersectionObserver + CSS 动画模拟滚动触发效果
当 Scroll-driven 不可用，又不想写完整 polyfill 时，IntersectionObserver是最轻量可靠的替代方案，尤其适合“滚动到视口才播放一次”的场景（如卡片渐入、标题高亮）：
- 给目标元素加一个基础类（如
.fade-in），其opacity和transform由@keyframes定义，但默认不触发 - 用
IntersectionObserver监听进入视口（isIntersecting === true），动态添加.animate类来启动动画 - 若需重播，每次进入都先移除再添加类名；若只需一次，观察到后调用
unobserve() - 避免用
window.onscroll手动计算getBoundingClientRect()——在快速滚动时易卡顿，且无法准确处理缩放、iframe 或 fixed 容器内的偏移
JS 滚动监听 fallback 的关键细节
如果必须用 JS 模拟滚动驱动（比如要精确控制视差位移比例），别直接监听scroll事件，改用requestAnimationFrame节流：
- 在
scroll回调里只记录scrollTop，不执行样式更新；真正更新放在requestAnimationFrame回调中 - 滚动进度计算用
(scrollTop - start) / (maxScrollTop - start)，而非固定像素值，确保响应式容器下仍准确 - 务必监听
resize事件并重新计算maxScrollTop，否则窗口缩放后动画范围错乱 - 对
transform等合成属性，加上will-change: transform可避免意外回流，但仅在动画活跃时添加，用完即删
真正容易被忽略的是：Scroll-driven 动画的触发精度依赖于滚动容器的“滚动上下文”是否干净——任何transform、filter或will-change都可能创建新的层叠上下文，干扰@scroll-timeline对容器边界的判定。测试时优先关掉这些样式，确认基础逻辑跑通后再逐步加回。
