设 threshold 为 0.1 时视频10%入视口即触发，0.5则需过半；但因回调异步批量、intersectionRatio为估算值，快速滚动时可能跳过中间阈值，导致监听0.5却收不到对应entry。
threshold 设为 0.1 和 0.5 的实际行为差异在哪
设 threshold 为 0.1 意味着：只要视频元素的 10% 高度进入视口，回调就触发；设为 0.5 则需过半才触发。但很多人误以为「只要设了 threshold 就能精准控制启停」——其实不是。IntersectionObserver 的回调是异步且批量触发的，intersectionRatio 是估算值，尤其在快速滚动时可能跳过中间阈值（比如直接从 0.05 → 0.6），导致你监听 0.5 却收不到 0.5 对应的 entry。
实操建议：
- 不要依赖单个
threshold值做开关决策，改用intersectionRatio > 0.2（启播）和intersectionRatio （停播）这类区间判断 - 对视频容器加
contain: layout paint，减少滚动抖动导致的 ratio 计算误差 - 避免把
threshold设成过高值（如0.9），小尺寸设备或窄容器下几乎无法触发
为什么 video.play() 在 iOS Safari 上常静音失败
iOS Safari 要求用户手势触发播放，哪怕视频本身是 muted，也必须满足「首次播放前有用户交互」这一前提。单纯靠 IntersectionObserver 触发 play() 会抛出 NotAllowedError: play() can only be initiated by a user gesture。
实操建议：
- 页面加载后监听一次
click或touchstart（任意位置），在事件回调里调用video.play().catch(() => {})建立播放许可，之后 IntersectionObserver 才能安全调用play()/pause() - 确保
标签带muted autoplay playsinline属性，playsinline防止全屏劫持 - 不要在
intersectionRatio === 0时立刻pause()，先检查entry.isIntersecting === false再执行，避免误判
滚动中频繁触发 play/pause 怎么防抖
快速上下滚动时，isIntersecting 可能在 true/false 间高频翻转，导致视频反复启停、解码器重置、画面卡顿。这不是 IntersectionObserver 的 bug，而是它按帧上报的自然行为。
实操建议：
- 用
setTimeout+ 标志位实现简易防抖：进入视口时设pendingPlay = true，延迟 100ms 后检查仍满足条件再play()；离开时同理设pendingPause - 不推荐用 Lodash 的
debounce，它会吞掉中间状态，可能错过关键帧 - 对多个视频实例，每个都维护独立的
isPlaying状态，避免全局锁造成串行阻塞
如何让“滚动到视口”真正反映用户意图
IntersectionObserver 默认以视口为参考系，但用户真正关心的是「是否在当前可见区域稳定停留」。比如视频刚滑入顶部 5px 就触发播放，但用户根本没看，只是快速划过——这不算有效曝光。
实操建议：
- 加一个持续时间判断：记录首次
isIntersecting === true的时间戳，仅当entry.intersectionRatio > 0.3 && now - firstEnterTime > 300才启动播放 - 对
visibility: hidden或display: none的父容器，Observer 会返回intersectionRatio: 0，但不会报错，需主动检查getComputedStyle(video).visibility - 如果视频被
transform: translateY()移动，部分旧版 Chrome 下boundingClientRect计算不准，建议改用position: relative + top
最易被忽略的一点：IntersectionObserver 不监听 DOM 结构变化。如果视频是懒加载进来的，必须等节点挂载完成再 new Observer，否则会漏掉首次进入事件。
