manifest.json配置safearea是最稳起点，需协同设置app-plus.safearea.background（主色调）和bottom.offset（多选"auto"），改后须重新运行；CSS用env(safe-area-inset-bottom)需fallback+JS动态取值；u-safe-bottom仅APP端生效且勿与manifest.auto重复。
manifest.json里配safearea是最稳的起点
直接改manifest.json是iOS端最可靠、最低侵入的方案，不需要写一行JS逻辑，也不依赖运行时判断。只要配置生效，原生层就会自动处理占位和背景填充。
关键点在于app-plus.safearea下两个字段必须协同设置：
-
background：填你App主色调，比如深色主题用"#1A1A1A"，浅色用"#F8F8F8"；别留默认"#FFFFFF"，否则iPhone上必出白条 -
bottom.offset：绝大多数页面选"auto"，它会让内容自动上移，同时用background色填满底部空白区 - 改完必须重新执行
npm run dev或点击HBuilderX的“运行到手机或模拟器”，热更新不触发manifest重载
env(safe-area-inset-bottom)在CSS里怎么用才不翻车
当需要页面级微调（比如某个按钮要刚好贴底但又不被遮挡），就得靠CSS环境变量。但它不是万能的，不同平台支持差异大，硬套会出问题。
安全写法是「双保险」fallback：
- 先写
padding-bottom: env(safe-area-inset-bottom);——iOS和部分安卓新机型能识别 - 再用内联
style覆盖：:style="{ paddingBottom: safeBottom + 'px' }"，其中safeBottom来自uni.getSystemInfoSync().safeArea.bottom - 初始化
safeBottom别设成0，设为null或0都行，但要在onLoad或onShow里重新取值赋值，避免首次渲染取不到 - H5端完全不支持
env()，支付宝小程序也不支持safeArea字段，得靠硬编码fallback（比如iOS设备safeBottom = 34）
为什么offset: "none"容易踩坑
看到“关闭安全区”就马上设offset: "none"？小心按钮直接消失。
这个配置等于告诉系统：“我不需要你帮我避让，我自己来”。但实际中很容易漏掉几处：
- 只加了
padding-bottom，没同步调整position: absolute类元素的bottom值，导致定位错乱 - 页面有滚动容器（如
scroll-view），它的height没减去安全区高度，内容被截断 - iOS真机上
screenHeight - windowHeight差值大于60px时，大概率存在不可见导航栏，光靠safeArea.bottom可能不准，得结合差值估算 - 全屏视频页确实适合
"none"，但必须配合navigationStyle: "custom"和titleNView: false，否则顶部状态栏还会干扰
uView的u-safe-bottom组件真能省事？
如果你项目已引入uView，u-safe-bottom确实是快速兜底方案，但它不是银弹。
它本质是根据uni.getSystemInfo动态插入一个带padding-bottom的空div，所以要注意：
- 只在APP端生效，微信/支付宝/H5都不走这个逻辑
- 如果manifest里
offset设为"auto"，原生层已经占位了，再加u-safe-bottom会导致底部双倍留白 - 它不处理背景色，白条问题还得靠
manifest.json里的background - 自定义组件里用它，得确保父容器没设
overflow: hidden，否则padding会被裁掉
真正难的不是某一行代码怎么写，而是得同时盯住三件事：manifest全局背景、CSS动态留白、JS运行时兜底值。少盯住一个，白条或遮挡就回来找你。
