offsetHeight不能直接用于绝对定位子元素，因其仅返回自身盒模型高度（如200px），不包含top/bottom偏移带来的实际占位；须用getBoundingClientRect().bottom减去父容器top获取真实底部落点，并遍历所有absolute子元素取最大值，配合ResizeObserver监听与min-height设置确保准确撑高。
为什么offsetHeight不能直接用
直接读取绝对定位子元素的 offsetHeight 并赋给父容器，大概率会错位。因为 offsetHeight 只返回它自身的盒模型高度（比如 200px），完全不包含 top: 40px 或 bottom: 20px 带来的实际占位偏移。视觉上它可能从父容器顶部往下压了 120px，但 offsetHeight 还是 200 —— 你设父容器 height: 200px，结果它只盖住一半。
真正要的是它在父容器坐标系里的“底部落点”。得用 getBoundingClientRect()，再减去父容器的 getBoundingClientRect().top。
- 别在
DOMContentLoaded立刻执行，DOM 渲染未完成，尺寸不准 - 多个
position: absolute子元素共存时，必须遍历取所有rect.bottom的最大值 - 若父容器有
padding-top或border-top，最终算出的高度要额外减掉这些值，否则会多出一截
如何用ResizeObserver监听并更新高度
ResizeObserver 是目前最稳妥的触发时机：它在元素内容、尺寸、甚至字体渲染完成后才回调，比 requestAnimationFrame 更精准，也比轮询高效。
关键不是观察父容器，而是观察每个绝对定位子元素 —— 它们的内容变化（如异步加载文本、图片解码、动态插入）才是高度变动的源头。
立即学习“Java免费学习笔记（深入）”；
- 对每个
position: absolute子元素调用ro.observe(el) - 回调里统一计算：
Math.max(...allRects.map(r => r.bottom)) - parentRect.top - 一次性写入父容器
style.minHeight（比height更安全，允许内容超出） - 如果子元素用了
transform: scale(1.2)，getBoundingClientRect()已含缩放效果，无需额外换算
多个绝对定位子元素共存时怎么取最大高度
常见错误是只处理第一个匹配到的 .box，结果下方另一个 bottom: 0 的元素被忽略，父容器切掉了它的下半部分。
必须显式收集全部目标节点，逐个算它们的视口 bottom 值，再和父容器内正常流内容高度（如有）取最大值。
- 用
parent.querySelectorAll('[style*="absolute"], [class*="abs"]')或加统一 data 属性（如data-abs="true"）来可靠筛选 - 对每个匹配元素调用
el.getBoundingClientRect()，提取bottom - 同时读取父容器内非绝对定位子元素的
offsetHeight（比如纯文本、display: block的 div），参与Math.max() - 最终设置：
parent.style.minHeight = Math.max(maxAbsBottom - parentTop, normalHeight) + 'px'
为什么min-height比height更合适
硬设 height 会让父容器变成刚性盒子：一旦子元素内容变多（比如文案从 2 行涨到 5 行）、或用户缩放字体，就会溢出或遮挡。而 min-height 保留了向上伸展的能力，只兜底最小显示范围。
它还能兼容某些边界情况：比如 JS 计算延迟导致短暂空白，或 ResizeObserver 尚未触发时，父容器至少有个最低保障。
- 不要写
height: 300px，改用min-height: 300px作为 fallback - 如果父容器本身有
padding，确保计算出的高度已扣除，否则min-height+padding会双倍撑高 - 当子元素靠
bottom: 0定位时，min-height比padding-bottom更可控 —— 后者无法响应 top/bottom 动态变化
真正难的不是算出那个数字，而是每次加 position: absolute 前，先问一句：这个元素在语义上，真的属于这个父容器的内容流吗？如果不是，强行撑高只会让后续响应式、可访问性、维护成本全跟着失控。
