直接给滚动容器加padding-bottom比动态算bottom更可靠轻量；仅当页脚高度不可控（如JS插入、字体缩放、键盘弹出）时才需动态计算，且应通过CSS变量而非直接操作style.bottom。
直接给滚动容器加 padding-bottom，值等于页脚渲染高度，比动态算 bottom 更可靠、更轻量。 动态计算 bottom 是兜底手段，只在页脚高度不可控（如 JS 插入、字体缩放、键盘弹出）时才值得上。
为什么动态改 bottom 常常白忙活
fixed 元素的 bottom 是相对于视口计算的，但视口本身在移动端会动态变化：iOS Safari 地址栏收起、软键盘弹出、甚至字体缩放都会导致 window.innerHeight 和实际可视区域不一致。你用 JS 算出的 bottom 值，可能刚设完就被浏览器重绘覆盖，或者在 resize 后失效。
- 单纯监听
resize事件，在 iOS 上无法捕获地址栏显隐——它不触发 resize - 用
getBoundingClientRect().bottom反推，必须等 focus 后setTimeout(, 0)才准，否则拿到的是键盘弹出前的位置 - 多个输入框共用同一底部区域时，
blur恢复逻辑容易漏掉或错序，导致 fixed 元素永久“悬空”
什么时候真该动 bottom？看这三类场景
只有当页脚高度无法通过 CSS 静态声明时，才考虑 JS 干预 bottom。典型包括：
- 页脚内容由 JS 动态插入（比如实时客服状态栏），且高度随文字长度浮动
- 页面启用系统级字体缩放（iOS「更大字体」设置），导致
60px高度实际渲染为72px - 软键盘弹出后，需要将页脚临时切换为
position: absolute并精确锚定在输入框下方（此时bottom是计算出来的安全间距，不是固定偏移）
如果非得动态算，别直接改 style.bottom
直接操作 element.style.bottom = '48px' 会强制重排，且和 CSS 中的 bottom: 0 冲突。正确做法是把偏移量抽成 CSS 自定义属性，由 JS 控制，CSS 负责渲染：
立即学习“前端免费学习笔记（深入）”；
footer {
position: fixed;
bottom: calc(var(--footer-offset, 0px) + env(safe-area-inset-bottom, 0px));
}
- JS 只需更新
document.documentElement.style.setProperty('--footer-offset', '48px') - 配合
env(safe-area-inset-bottom)保证 iPhone X+ 圆角区不被遮挡 - 键盘弹出时，用
visualViewport?.height替代window.innerHeight，更接近真实可视高度
真正难的不是怎么算，而是怎么判断“该不该算”。多数遮挡问题，其实只需要确认滚动容器是谁、然后给它加对 padding-bottom 就解决了。动态逻辑一加，就绕不开 resize/focus/blur 的状态同步，稍有疏漏，页脚就在半空中飘着——这种失控感，比留白多 10px 更让人头疼。
