手机门户中嵌入的在线编辑页，软键盘弹出后遮住输入区域，不能只看编辑器内部上报的高度。先确认这个数值属于宿主顶层页面，还是 iframe 自己的布局范围；子文档认为空间没变，不代表用户仍看得到相同区域。
本文讨论移动网页 SDK 接入中的几何边界，面向负责门户与编辑器衔接的开发者。以下观察与用例均为设计建议，未在手机、应用内网页或某个产品版本上实测。免插件接入也不等于所有终端具有同样的键盘和视口行为。
布局使用的空间，与用户此刻看见的部分要分开
MDN 的 VisualViewport 说明区分布局视口与视觉视口：页面用于布局的区域，与屏幕上此刻可见的部分并非总是相同。捏合缩放、屏幕键盘等可能改变视觉视口，而布局视口没有发生对应变化。
因此，一个定位在布局底部的工具栏，不能只凭“底部为零”就证明仍可见。排障应分别观察输入焦点、工具栏实际位置、可见区域与滚动情况。只收到 resize 事件，或只看到页面高度未变，都不足以结束判断。
高度差也不能直接作为键盘高度。缩放、地址栏和页面偏移等因素可能同时变化，应记录发生了什么交互，再解释数值；不要把任意高度减少都归因于键盘。
iframe 内测量的，不是整部手机的可见区域
同一份 API 说明明确：每个窗口有自己的 VisualViewport；只有顶层窗口的视觉视口才可能与布局视口不同。iframe 的相关指标对应自身的布局范围，不能直接拿来当作宿主页扣除软键盘后的可见区域。
在一个假设例子中，宿主页仍给编辑器容器保留原高度，键盘却遮住屏幕下方。子文档可能仍报告原来的内部尺寸；问题并不因为这个数值“正常”就消失。反过来，宿主缩小了容器，也要确认内部编辑页如何响应，不能从外框变小推出输入框自动滚入可见位置。
MDN 的视口概念文档也说明，iframe 内的视口单位与媒体查询依照自己的视口工作。因此，给子页面设置某个 vh 高度，不能替代对宿主容器和手机实际可见部分的核对。
先对齐坐标和责任，再讨论适配
接入方可以将证据分成三层：宿主记录顶层可见区域和滚动状态；容器维护者记录 iframe 外框的尺寸、位置与裁切；编辑器按其正式支持方式说明内部焦点和控件表现。跨源时，不能假设宿主可以直接读取子文档 DOM，也不能让子页面随意访问顶层对象作为通用方案。
VisualViewport 的尺寸与偏移以 CSS 像素表达。将它们与截图物理像素、屏幕尺寸或另一个窗口坐标直接相减，容易制造新的误判。应注明测量上下文、单位、缩放状态与采集时刻；文档不处于完全活动状态时，window.visualViewport 还可能为 null，不能把无有效读数解释成高度为零。
实际调整由维护相应页面的一方完成，并通过产品支持的扩展或布局接口验证。不要直接改写 SDK 私有 DOM，也不要在没有接口契约的情况下，把宿主与子页各自的高度修正叠加起来。
一个 viewport 参数不是所有终端的修复方案
viewport 元数据文档列出了 interactive-widget 对交互界面影响视口的不同模式。它描述的是可声明的行为，不能据此推定项目中的浏览器或应用内网页都支持，也不能保证改一个参数就修复编辑器。
若准备采用相关配置，先确认由哪个顶层页面设置、目标运行环境是否支持，以及会怎样影响布局与滚动，再在隔离环境复验。不应让用户通过禁用页面缩放来绕开遮挡；这样可能妨碍需要放大阅读的使用者。
系统浏览器与应用内网页需要分别验证。历史浏览器版本文章可以解释某次行为变化，但不是当前手机兼容清单；不能用桌面调成 390px 的预览代替实体手机软键盘验证。
验收要能解释遮挡发生在哪一层
准备一份虚构测试文档和明确的输入任务，记录设备、系统、浏览器或宿主应用及网页容器版本。下面各项均为待执行条件，没有实测结果。
| 交互 | 同时记录 | 独立判断 |
|---|---|---|
| 聚焦并展开键盘 | 顶层可见区域、外框、焦点位置 | 输入内容能否看见 |
| 滚动到工具栏 | 宿主与内部滚动、控件实际位置 | 必要操作能否到达 |
| 关闭键盘或旋转 | 尺寸、偏移与布局恢复过程 | 是否残留遮挡或空白 |
| 捏合缩放后再输入 | 缩放状态与焦点可见性 | 不把高度变化都当作键盘 |
记录应说明“外框未随可见范围变化”“外框变化但内部控件仍被挡住”或“滚动后能到达但操作无响应”等具体结果，交给对应维护方复现。输入看得见、操作能到达和内容已保存是三项结果；最后还需按实际保存流程重新打开核对，不能由屏幕几何推出保存成功。
评估石墨办公文档中台私有部署嵌入移动门户时，可带上实际入口、终端与一条键盘展开后的输入路径，预约接入演示，确认宿主和编辑页各自提供的适配接口与验证范围。本文不推定产品内部采用哪种视口策略，也不宣称已完成任意手机适配。也可以先看私有化部署方案，了解部署形态与交付范围。