移动端安全区设计：底部操作栏与横屏怎样避免遮挡

移动端安全区不是给页面四周统一加一圈留白，而是先分清系统可能覆盖的区域，再决定背景、内容和控件分别如何延伸。登录页、底部导航、表单和全屏图片的处理方式不同；同一页面转为横屏后，原来的顶部和底部假设也可能失效。设计交付时，至少要写清 top、right、bottom、left 四个方向的避让规则，以及按钮在安全区内的可点击边界。

先把设备窗口拆成三层

第一层是可以延伸到屏幕边缘的背景，例如纯色、渐变或图片。第二层是需要保持阅读位置的内容，包括标题、表单字段和列表文字。第三层是用户要触碰的控件。背景可以铺满全屏，但内容和控件不应因为铺满而被刘海、状态栏或底部手势条遮挡。把三层画在同一张设备画板上，评审时更容易回答“这里的空白是设计间距，还是系统安全区”。

在 移动端 UI 基础规范的页面层级之外，再给每个关键画板补一组安全区标注：顶部 inset、底部 inset、左右 inset、内容起始线和最小点击框。标注值应来自目标平台或研发约定，不能用一张设备截图的像素直接推断全部机型。

四类页面分别怎么避让

登录页通常要让背景和品牌图形延伸到屏幕边缘，标题、输入框和主按钮则放在内容安全区内。底部导航要把导航栏背景延伸到底部，但图标和文字不能贴着手势条。表单页需要同时保护顶部返回按钮和底部提交按钮，滚动时应保留最后一个字段的可见性。全屏图片或视频可以使用全出血布局，但关闭、播放和分享等控件必须落在可操作区域内。

把 inset 规则交给研发

交付文档不要只写“适配刘海屏”。应把安全区作为变量说明，并指出变量影响哪一层。Web 页面常见的环境变量是 safe-area-inset-top、safe-area-inset-right、safe-area-inset-bottom 和 safe-area-inset-left；MDN 对 env() 的定义可作为语义依据。研发仍需结合目标容器、浏览器和系统栏方案确认实际值，设计稿不替代运行时验证。

可以用“基础间距 + 环境 inset”的方式表达，而不是把某个设备的结果写死。例如底部操作区的内边距由常规间距加底部安全区组成，按钮本身仍保持一致的高度和点击范围。对左右两侧同样处理，避免横屏后把内容挤到一边。底部操作栏可用 padding-bottom: calc(16px + env(safe-area-inset-bottom, 0px)) 表达这一约定：16px 是该项目选定的基础间距，不是设备安全区通用值。若外层已消费同一 inset，内层就不要再加一次。safe-area 变量也不能当作通用的键盘高度，键盘遮挡需要单独验收。Android 的 edge-to-edge 页面需要特别说明系统栏是否覆盖内容、是否由容器负责消费 inset，不能把 iOS 的标注原样复制过去。

以“保存地址”操作栏为例，给研发的标注可以写成：背景延伸到窗口底边，按钮下方保留项目间距 16px，再由操作栏容器叠加 bottom inset；表单滚动区另外留出操作栏所占空间，最后一行详细地址不能滚到按钮背后。这里加法表示两种间距都要保留。若项目约定是“安全区与 16px 取较大值”，则应改用 max(16px, env(safe-area-inset-bottom, 0px))，两种约定不能混写。

Web 页面还要核对 viewport 设置与浏览器实际返回值，不能因为写了 env() 就假定四边一定非零。Android 则应区分系统栏、屏幕开孔和系统手势对应的 inset；例如横向滑动控件临近屏幕边缘时，即使没有被遮挡，也可能与系统返回手势冲突。优先依据平台的 inset 类型说明决定需要避让的区域。

横屏不是把画板旋转九十度

横屏验收要重新判断信息优先级。顶部标题可能从居中改为左对齐，底部导航可能转为侧边操作，表单可能需要两列或滚动容器。不要为了“填满空间”增加装饰内容，先保护返回、提交、关闭和媒体控制等任务路径。对于登录页，优先确保键盘出现时仍能看到当前字段和提交动作；对于全屏图片，优先确认关闭按钮和手势区域保持可触达。

在 多端适配方法中建立竖屏、横屏和窄屏三个状态，给每个状态标明设备方向、可用宽高和安全区假设。这样评审时可以区分“布局改变”与“元素被遮挡”，也方便研发针对具体状态回归。

一张验收表覆盖真实设备边界

安全区检查完成后，再用移动端 UI 设计清单补齐导航、反馈和控件一致性，避免只解决遮挡却遗漏整体任务。

触控目标、焦点和对比度还应结合 无障碍触控与焦点检查复核。在 Pixso 中保留同一套联系人、联系电话、详细地址和保存按钮，建立竖屏、横屏与键盘打开三个画板。为每个画板单独标出背景边界、内容安全线和按钮点击框，在底部操作栏旁注明由它消费 bottom inset，避免交付时只留下一个含义不清的总高度。

可以在 Pixso 中标注移动页面安全边界，把本项目的间距约定放到对应控件旁。设备旋转和软键盘出现后的可用高度，交给目标设备上的页面继续验证。

标注时把“能铺满”和“能点击”分开

安全区评审最容易出现的误会，是把所有内容都往内缩，结果背景出现一圈不必要的空白；或者让按钮跟着背景铺到边缘，结果手势条覆盖了点击区域。交付时建议在画板上使用三种不同的标记：背景延伸线、内容安全线和控件点击框。背景延伸线只说明颜色或图片能到哪里，内容安全线说明文字和字段从哪里开始，点击框则说明用户实际可以触碰的面积。

对于顶部区域，返回按钮、标题和状态提示可以有不同的起始线。返回按钮通常需要留出设备边缘和触控余量，标题要保持与正文的视觉对齐，状态提示则要避免被系统栏或摄像头区域遮挡。对于底部区域，操作栏背景可以延伸到底边，但按钮组、文字和安全提示要跟随 bottom inset 上移。横屏后左右两侧都可能成为需要避让的边界，因此不要只保留一个“底部留白”标注。

常见失败方案和修正顺序

第一种失败是把某一台测试机的像素值写成所有设备的固定间距。修正时应先记录目标平台和容器，再把环境值作为变量交给研发。第二种失败是只测试首屏，忽略键盘、滚动和弹出层。修正时要增加键盘出现、底部提交、全屏媒体和弹窗关闭四个状态。第三种失败是旋转后只看视觉是否居中，没有检查主要按钮和返回动作是否仍可达。修正时按用户任务重新排布，而不是机械旋转画板。

验收顺序可以固定为：先看四边 inset 来源，再看控件是否被遮挡，然后看键盘和滚动，最后检查竖屏/横屏切换。每一步都留存视口、系统版本、浏览器或容器信息。若某个平台暂时无法测量，应该记录为待确认条件，而不是用“兼容全部设备”替代证据。

交付时写清由哪个容器消费 inset

设计、开发和测试经常使用不同的词描述同一个问题。设计师说“底部留白”，开发说“padding”，测试说“按钮被系统栏盖住”，三句话很难直接对应。采用累加间距的项目，交付时可以写成“底部安全区 + 常规间距 = 操作区内边距”，并注明该值由谁提供、在哪个容器消费。顶部、左右边界同样采用这种写法，问题单就能直接定位到变量、容器或控件。

评审记录还应区分设计要求和平台事实。设计要求是内容不可被遮挡、主要动作可触达；平台事实是某个目标容器在某个方向下返回了多少 inset。若平台事实尚未确认，只写“待研发回填”，不要用估计值占位。这样可以避免设计稿先定死数值，后续为了迁就一个设备而修改全部状态。

当页面包含浮层、键盘或全屏媒体时，边界要按层级分别记录。浮层可能拥有自己的滚动区，键盘可能改变可用高度，媒体控制可能在横屏状态移到侧边。把所有内容都交给外层 padding 会导致内层控件重复避让，最终出现过大的空白。逐层说明“谁消费 inset”比再画一圈间距更可靠。

四个边界用例要单独回归

安全区的常规状态通过后，还要回归四个容易漏掉的边界：设备旋转中、系统字体放大、键盘打开和弹层叠加。旋转中不要让按钮短暂落到屏幕外；字体放大后，顶部标题和底部操作区仍应有可读间距；键盘出现时，表单最后一个字段和提交动作要能滚到可见位置；弹层叠加时，新的关闭按钮不能被底部手势区覆盖。每个用例都记录触发动作、预期安全线和恢复动作。

如果浏览器或原生容器对 inset 的返回值不一致，先把差异记录为环境问题，再决定由外层容器统一处理还是由页面组件分别处理。页面组件重复消费同一个 inset，会造成双倍留白；外层完全不消费，又可能让浮层越过边界。设计稿可以用“消费者”字段标出责任方，减少实现阶段的猜测。

参考资料

• Apple Human Interface Guidelines：Layout，用于理解设备窗口与内容布局。
• Android Developers：Display content edge-to-edge，用于确认 edge-to-edge 与系统栏 inset 的处理边界。
• MDN：env() CSS function，用于核对 safe-area 环境变量语义。