IntersectionObserver 是检测元素是否进入视口的现代标准方案，需配置 threshold、root 等参数并配合 will-change 和 class 切换实现顺滑渐现动效。
用 intersectionObserver 检测元素是否进入视口
纯 CSS 无法可靠判断“元素是否出现在视口”，@keyframes + opacity 只能做静态过渡，不触发时机。必须靠 JS 驱动，而 IntersectionObserver 是唯一现代、低开销、兼容性够用（Chrome 51+/Safari 12.1+/Firefox 55+）的方案。
常见错误是用 scroll 事件监听 + getBoundingClientRect()，卡顿明显，且容易漏判快速滚动或初始不在 DOM 的元素。
- 观察器初始化时传
{ threshold: 0.1 }表示元素 10% 进入视口就触发，比threshold: 0更早响应，避免用户已看到才动效 - 不要在回调里直接改
style.opacity—— 会强制同步重排；统一用 class 切换，让 CSS 控制过渡 - 记得调用
unobserve()防止重复触发（比如只动一次）或内存泄漏（长列表）
opacity + transition 实现渐现，但必须配 will-change
只写 opacity: 0; transition: opacity 0.4s ease; 在某些浏览器（尤其是 Safari 和低端 Android）会出现闪帧或延迟启动。根本原因是 opacity 变化未被提前告知渲染引擎优化路径。
正确做法是在元素默认状态（未进入视口前）加上 will-change: opacity;，或更稳妥地用 transform: translateZ(0) 触发硬件加速。
立即学习“前端免费学习笔记（深入）”；
- 别把
will-change写在动效 class 里——它得在元素挂载时就存在，否则无效 - 过渡时间别超过 0.6s，人眼对 >600ms 的入场动效敏感，易觉“慢”
- 慎用
ease-in-out：开头太缓，用户刚看到元素时还没开始变；ease或cubic-bezier(0.34, 1.56, 0.64, 1)更自然
为什么不能只靠 visibility: hidden 切换
visibility: hidden 保留布局空间，但和 opacity: 0 混用会出问题：如果元素有子元素设置了 pointer-events: auto，即使父级 opacity: 0，鼠标悬停仍可能触发事件；而 visibility: hidden 会彻底禁用交互，但过渡不可见——你根本看不到“渐现”过程。
- 必须用
opacity做视觉过渡，用pointer-events: none配合控制交互时机（例如等 opacity 到 1 后再启用） - 别依赖
display: none控制初始隐藏：它会让元素脱离文档流，IntersectionObserver无法观测到其位置，首次进入可能不触发 - 若需 SEO 友好，初始状态用
opacity: 0; visibility: visible;，而非display: none
移动端 iOS Safari 的 IntersectionObserver 兼容细节
iOS 12.2+ 支持 IntersectionObserver，但有个坑：当页面有 overflow: scroll 的容器（非 body），且目标元素在该容器内滚动时，observer 默认只监听 body 滚动，不会响应容器内滚动。
解决办法是显式传入 root 参数：
new IntersectionObserver(callback, {
root: document.querySelector('.scroll-container'),
rootMargin: '0px',
threshold: 0.1
});
- 如果没指定
root，iOS Safari 下容器内滚动的元素大概率不会触发回调 -
rootMargin推荐写成'20px'而非'20px 0px'—— iOS 对多值解析偶尔不稳定 - 不要在
callback里调用el.scrollIntoView()，会打断 observer 的状态跟踪，导致后续不再触发
will-change 没提前加。 
