核心是用flex-column布局让主体内容flex:1自动撑开、将菜单“推”到底部，避免fixed定位在iOS软键盘等场景下的错位问题；需设html/body为min-height:100vh并清除默认margin，根容器用flex-column，菜单容器显式设高度且justify-content才生效。
直接用 flex-direction: column 实现移动端底部固定菜单，核心不是“把菜单塞到底部”，而是让主体内容自动撑开、把菜单“推”下去——这样既避开 position: fixed 在 iOS 上的软键盘错位、安全区遮挡、滚动抖动等老问题，又能保持文档流完整性。
为什么必须给 html 和 body 设 height/min-height
Flex 布局要生效，父容器得有明确的高度参考。浏览器默认 body 高度由内容决定，不是视口高度；不设 min-height: 100vh，flex: 1 就没空间可占，菜单自然浮在半空。
-
html和body都要加min-height: 100vh（不用height: 100vh，防 iOS 地址栏缩放导致截断） - 移除
body默认margin（通常是 8px），否则 flex 容器实际高度会少一截 - 根容器（比如
.app）设display: flex; flex-direction: column;，不能只套在body上就完事——DOM 层级和重置必须到位
主体内容用 flex: 1 而不是 margin-top: auto
两者都能推菜单到底部，但 flex: 1 更可控：它让内容区真正“占满剩余空间”，滚动时不会因高度突变而失位；而 margin-top: auto 在内容超长或动态加载后容易计算偏移。
-
.main或对应内容容器加flex: 1，别写flex-grow: 1—— 虽等价，但flex: 1是简写，更少出错 - 如果内容区需要滚动，加
overflow-y: auto；别依赖外部容器滚动，否则 iOS Safari 可能卡住 - 不要给底部菜单容器设
flex-shrink: 0以外的弹性属性，否则小屏下可能被压缩变形
底部菜单容器必须显式设高度，且 justify-content 才有效
justify-content: space-around 不是“自动均分”，它依赖父容器有明确宽度和高度基准。fixed 定位下失效，是因为脱离文档流；而 flex 布局里，没高度的容器会让 space-around 失去垂直对齐参考。
立即学习“前端免费学习笔记（深入）”；
- 菜单容器（如
.tabbar）必须设height: 60px或min-height: 60px（别用vh单位） - 内部用
display: flex; justify-content: space-around;，但首尾项会留白——真机上更稳的是justify-content: space-between;+ 四个子项都flex: 1 - 每个菜单项加
flex: 1 1 0; min-width: 0;，防止 Safari 按文字长度撑宽，破坏等分 - 图标统一用
<svg>或字体图标，禁用<img>，避免加载延迟引发布局抖动
安全区与软键盘场景下怎么不靠 JS 补救
iOS 的 env(safe-area-inset-bottom) 是 CSS 原生方案，但只解决刘海/手势条遮挡，不解决软键盘弹出时视口高度突变。关键在于：菜单本身不参与滚动，所以它的位置应由布局“预留空间”决定，而非靠 JS 监听重算。
- 菜单容器外层（比如
.tabbar-wrapper）加padding-bottom: env(safe-area-inset-bottom, 0px);，并 fallback 为padding-bottom: 60px; - 菜单容器自身仍保持
height: 60px，这样安全区空间是“额外加的”，不影响布局结构 - 别在 JS 中读取
window.innerHeight动态设 padding——iOS 上这个值在键盘弹出时不可靠 - 如果菜单里有输入框（如搜索入口），确保
focus()后调用scrollIntoView({ block: 'nearest' })，且放在setTimeout(() => {}, 0)或Promise.resolve().then()中，否则 iOS 可能滚动不到位
最常漏的是两处：一是忘了重置 body 的默认 margin，导致 flex 高度计算偏差；二是菜单项没加 min-width: 0，在 Safari 里文字一长就挤垮等分。这两点不处理，哪怕代码全对，真机上也大概率“看起来不对”。
