table 中 loading="lazy" 常失效，因浏览器将 table 视为不可分割块，导致 IntersectionObserver 误判、rootMargin 失效、滚动根丢失；需用 data-src + IntersectionObserver 手动控制，设固定宽高或 aspect-ratio，配合 base64 占位图，并同步处理 srcset/sizes。
表格里加 loading="lazy" 为什么经常失效
因为 table 的渲染机制和滚动根计算特殊：浏览器默认把 table 当作“不可分割的块”，loading="lazy" 依赖父容器可滚动且能准确判断视口位置，而 table 内部 tr/td 没有独立滚动上下文，容易导致 IntersectionObserver 误判或浏览器直接降级为 eager。常见现象是所有图片在页面加载时就发请求，完全不懒。
-
table元素本身不支持rootMargin精确触发，即使设了rootMargin: "200px"，实际加载时机仍不稳定 - 若
table被包裹在overflow: hidden+transform的容器里（比如某些 UI 框架的卡片组件），Chrome 会丢失滚动根，loading="lazy"彻底失效 -
td中图片未设width/height时，表格自动撑开再收缩，引发 CLS，浏览器为防抖动主动跳过懒加载逻辑
用 data-src + IntersectionObserver 是唯一靠谱方案
必须绕过原生 loading 属性，手动控制 src 赋值。关键不是“能不能懒”，而是“怎么让表格单元格里的图片不破坏布局”。
- 给
img设固定宽高或aspect-ratio（如style="aspect-ratio: 4/3; width: 100%;"），否则td高度会随图片加载突变 -
src放 base64 占位图：src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw=="，体积小、无请求、不触发重排 - 真实地址存在
data-src，JS 触发后只改img.src，不碰srcset/sizes—— 否则响应式图片在表格中会错尺寸 - 观察器必须监听
td或tr，而不是img本身：表格行可能比单张图更早进入视口，提前触发更稳
表格响应式图片的 srcset 同步陷阱
表格常用于数据报表、商品列表等场景，图片往往带 srcset 适配不同屏幕宽度。但 loading="lazy" 不管 srcset，手动懒加载时极易漏同步。
- 必须同时存
data-srcset和data-sizes，不能只存data-src - 赋值时顺序要对：
img.src = img.dataset.src; img.srcset = img.dataset.srcset || ""; img.sizes = img.dataset.sizes || ""; - Safari 对空
srcset敏感：如果dataset.srcset为空，赋值前得先清空img.srcset = ""，否则可能加载失败或 fallback 到src - 表格列宽动态变化（如 resize 列）时，
sizes计算依赖父容器宽度，需监听resize并重新计算，但成本高——建议固定列宽或用vw单位避免
最易被忽略的兼容性断点
不是所有浏览器都把 table 当成标准滚动容器，尤其旧版 Safari 和部分安卓 WebView。降级逻辑不能只看 IntersectionObserver 是否存在，还得检查 getBoundingClientRect() 返回值是否合理。
立即学习“前端免费学习笔记（深入）”；
- 用
img.getBoundingClientRect().top 做 fallback 判断，乘以 1.2 是为了提前加载，弥补 <code>scroll监听不准的问题 - 别在
scroll事件里直接调用getBoundingClientRect()—— 每次滚动都查 DOM，卡顿明显；至少节流到 60fps（requestAnimationFrame包裹） - 动态插入的表格行（如 AJAX 分页），必须在
insertAdjacentHTML后立刻调用observer.observe(tr)，不能等DOMContentLoaded—— 否则新行永远不加载
表格里图片懒加载真正难的从来不是 JS 逻辑，而是让 td 高度不跳、srcset 不错、滚动不卡——这三处一松，懒加载就变成布局抖动加载。
