性能优化：图片懒加载与无限滚动实现技巧

• 每次插入新数据后，调用 observer.observe(sentinel)（如果之前已解绑需重新绑定）
• rootMargin 设为 '0px 0px 300px 0px'：仅向下扩展 300px，确保用户还有约半屏距离时就触发加载，体验顺滑
• 回调中检查 isIntersecting，为防重复触发，立即 unobserve(sentinel)，待新数据渲染完成后再重新 observe
• 加载中可禁用滚动监听或加 loading 状态，避免快速滚动导致多次并发请求

性能感知的关键细节：节流、销毁与降级

“性能感知”不是靠加功能，而是靠克制和兜底：

• 不用手动节流函数包裹回调——IntersectionObserver 本身是异步且浏览器原生优化的，但避免在回调里做重绘操作（如直接改大量 DOM），优先用 requestIdleCallback 或分片更新
• 页面卸载或组件销毁时，务必调用 observer.disconnect()，否则监听器持续驻留内存，尤其 SPA 中易引发内存泄漏
• 对不支持 IntersectionObserver 的旧浏览器（如 IE），降级为 scroll + getBoundingClientRect 轮询，但加上 throttle(100ms) 和 cancelAnimationFrame 清理机制
• 移动端注意：Safari 旧版本对 rootMargin 百分比支持不稳定，建议统一用 px 单位；iOS WebKit 中若页面有 transform，可能影响根容器判定，此时显式传入 root: null（即 viewport）更可靠

组合使用：懒加载 + 无限滚动共存时的注意事项

当列表项本身含图片，且列表又支持无限滚动，二者会叠加触发时机，需协调资源节奏：

• 无限滚动的 sentinel 应放在所有图片懒加载元素之后，确保它最后进入检测区，避免因图片加载慢而误判“已到末尾”
• 图片加载完成可触发 img.onload，但不要在此回调里直接调用无限滚动加载——应由 sentinel 主导，图片只是内容的一部分
• 网络较弱时，可动态调整 rootMargin：例如根据 navigator.connection.effectiveType，从 '300px' 改为 '600px'，换取更早加载机会
• 服务端支持时，首屏图片走同步 HTML 渲染，后续图片才走懒加载，既保障首屏速度，又减轻 JS 负担

不复杂但容易忽略。真正影响体验的，往往不是“能不能加载”，而是“什么时候加载、加载多少、失败怎么兜住”。IntersectionObserver 提供了精准的时机接口，剩下的，是根据场景做克制的决策。

今天关于《性能优化：图片懒加载与无限滚动实现技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！