必须给主内容区域加padding-bottom，值等于fixed元素实际高度（含padding、border），因fixed脱离文档流，margin-bottom在flex/grid中易折叠失效，而padding-bottom稳定可控；需配合viewport-fit=cover、env(safe-area-inset-bottom)及CSS变量实现iOS安全区与Android兼容适配。
必须给主内容区域加 padding-bottom，值等于 fixed 元素的实际高度（含 padding 和 border），不能依赖 margin-bottom 或指望浏览器自动避让。
为什么 padding-bottom 是唯一可靠选择
fixed 元素完全脱离文档流，主内容不会“感知”它的存在。加 margin-bottom 在多数布局中会失效——尤其在 flex 或 grid 容器里，外边距会被折叠或忽略；而 padding-bottom 是内容区域内部的留白，稳定、可控、不触发重排。
- 值必须匹配 fixed 元素的**实际渲染高度**：比如
height: 60px+padding: 12px+border: 2px→ 总高 84px，写死60px一定遮挡 - 优先作用于最外层内容容器（如
#app或main），而非body—— 避免影响scrollHeight、IntersectionObserver等 API 判断 - 配合
box-sizing: border-box，确保 padding 不额外撑大容器尺寸
如何适配 iPhone 底部安全区和软键盘
仅靠固定值无法覆盖 iOS 的手势条和键盘弹出场景。需用 env() 函数动态叠加：
- 先在
<head>加：<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">，否则env(safe-area-inset-bottom)不生效 - 定义统一变量：
:root { --nav-height: 60px; } - 主内容区写：
padding-bottom: calc(var(--nav-height) + env(safe-area-inset-bottom, 0px)); - Android 旧版忽略
env()会 fallback 为0px，无副作用；iOS 返回约34px（iPhone X+）
为什么不要把 fixed 导航栏放进 flex 容器
常见错误是把整个页面包进 display: flex; flex-direction: column，再把导航栏作为子元素放进去——这会让 fixed 失效或行为不可控。
立即学习“前端免费学习笔记（深入）”；
- fixed 元素一旦声明，就脱离父容器，不再受 flex 排布约束；强行塞进去反而容易因父容器
overflow或transform触发新层叠上下文，导致z-index失效 - 正确结构是：flex 容器只管主内容高度（
flex: 1），fixed 导航栏与之同级、独立定位 - 若页面需软键盘下保持位置稳定，
position: sticky并不可靠——iOS Safari 对bottom: 0支持差，微信 WebView 基本不认，不如直接用 flex +padding-bottom组合
移动端键盘弹出时的隐藏陷阱
iOS Safari 键盘弹出会压缩 visualViewport，但 fixed 元素坐标卡在旧位置，造成“上浮”错觉。这不是样式问题，而是浏览器定位机制限制。
- 绝对不要在 fixed 导航栏内部放
<input>或<textarea>—— 这会强制重排视口，加剧错位 - 所有可聚焦元素应加
scrollIntoView({ behavior: 'smooth', block: 'nearest' })，确保聚焦时不被遮挡 - 若用 JS 监听
focusin/blur，必须同步更新padding-bottom值，否则键盘收起后内容仍被顶穿 - 微信 WebView 中
env()支持不稳定，需 UA 判断降级到纯padding-bottom: var(--nav-height)
真正难的不是算高度，而是意识到 fixed 的“固定”是假固定——它锚定的是初始视口，而移动端视口本身就在变。所有方案都得围绕“内容主动避让”展开，而不是幻想 fixed 能自适应。
