隐藏元素中的图片天然不触发懒加载，因loading="lazy"依赖布局流和可视性判断，脱离文档流或明确不可见时浏览器直接跳过IntersectionObserver。
隐藏元素中的图片（如 display: none、visibility: hidden、opacity: 0 或被折叠的 Tab/模态框）**天然不触发懒加载**——这不是 bug，而是浏览器设计使然：loading="lazy" 依赖布局流和可视性判断，脱离文档流或明确不可见的容器会让浏览器直接跳过 Intersection 观察，甚至忽略 loading 属性本身。
为什么隐藏区域里的图片不加载？
浏览器只对「处于正常文档流中、尺寸可计算、且滚动容器能被正确识别」的 启用懒加载逻辑。以下情况会导致完全失效：
-
display: none的父容器：元素不参与 layout，浏览器无法测量其位置，IntersectionObserver 无法触发 -
visibility: hidden或opacity: 0：虽保留在 DOM 中，但多数浏览器（尤其 Safari 和旧版 Chrome）会跳过懒加载判定 - Tab 页签、手风琴折叠区、模态框初始隐藏内容：若整个容器用
hidden属性或 class 控制显隐，内部在隐藏状态下不会被观察
- 使用
transform: translateY(-9999px)等“伪隐藏”方式：部分浏览器仍视为“已渲染”，但因位置异常导致 rootMargin 计算失准，加载时机紊乱
正确处理隐藏区域图片的加载时机
核心原则：**不靠“等它出现再懒加载”，而是在它即将可见前主动触发加载**。具体分场景处理：
-
Tab 切换或手风琴展开：监听切换事件，在显示前手动加载目标区域内的图片
例如：tabPanel.addEventListener('show', () => { loadLazyImgsIn(tabPanel); }); -
模态框（Modal）：在
modal.show()调用后、动画开始前，遍历并触发内部.lazy-img元素的加载逻辑 -
动态插入的隐藏内容（如 Vue/React 渲染）：确保内容挂载到 DOM 后，立即调用
observer.observe(img)，而不是等滚动触发 -
服务端渲染（SSR）+ 客户端水合（hydrate）：首次 hydrate 时检查该区域是否已在视口内（
el.getBoundingClientRect().top < window.innerHeight），是则立刻加载，避免白屏
替代方案：预加载关键隐藏图（慎用）
对用户高频打开的隐藏区域（如默认第二个 Tab、常用弹窗），可提前预加载其中的关键图片，但需控制范围：
立即学习“前端免费学习笔记（深入）”；
- 仅预加载首张主图或占位图，避免全量加载
- 用
<link rel="preload" as="image" href="xxx.jpg">，且确保 href 与后续完全一致（否则重复请求）
- 不要给已加
loading="lazy"的图再 preload——语义冲突，反而增加资源竞争
务必避开的错误做法
这些操作看似“省事”，实则无效甚至有害：
- 给
display: none的加
loading="lazy"：属性会被忽略，图片可能根本不会发起请求 - 把
loading="lazy"写在<source>上：该属性只对<img>生效，<picture>内无效 - 依赖 scroll 事件轮询判断隐藏区域位置：性能差、不准，且无法感知非滚动触发的显示（如点击弹出）
- 用
onload+display: none模拟懒加载：display: none不阻止请求，只是不渲染，流量照耗
