表单是成交发生的地方，也是 WebView 最先背叛你的地方。结账、注册、搜索框——每一个要用户输入的屏幕，都是引擎和操作系统在键盘、光标、输入法上意见不一的屏幕。用户感受到的是卡顿、字段乱跳、字打不进去。他们不会去调试，只会放弃购物车。
不会调整大小的键盘
iOS 上，软键盘弹出时 WKWebView 的表现和 Safari 不一样。窗口不缩放；window.innerHeight 不缩小；position: fixed 的底部栏原地不动、被键盘盖住。修法是手工接上 Visual Viewport API 去偏移你的工具栏——这是为开放 Web 写的商家页永远不会做的事。更糟的是，当页面底部的输入框获得焦点，WKWebView 会自动把它滚进视野，但滚动目标有时会选错：字段跳到屏幕外、或者卡在键盘下面。而且 iOS 禁止程序化聚焦，以防网页擅自弹出键盘骚扰用户，于是任何想推进光标的流程都得等用户手势。一份在桌面 Chrome 和移动 Safari 都正常的表单，一进 WebView 就跑偏。
会吞掉你字符的输入法
Android 上，输入法编辑器——把拼音或假名变成中文、日文、韩文的那东西——正是 WebView 表单悄悄丢数据的地方。组字过程中，compositionend 落地时可能少一个字、甚至少一整段；光标冻结在开头直到组字结束；受控输入框把中间态拼音回写进 state，会污染字段、重复音节、或陷入死循环。一份 2026 年记录的案例显示，Android WebView 的语音输入在组字里带换行时，第一段整段丢失——文字从未进入 DOM。同一段代码在浏览器标签页里正常，进了 WebView 就不行，因为引擎在组字期间重建了块级 DOM，组字区域被作废。
消失的密码自动填充
把登录页从 Safari 搬进 WKWebView，密码管理器的填充提示常常直接消失。系统 AutoFill 依赖两个条件：WebView 必须用默认的 WKWebsiteDataStore，且 App 必须配置带有 webcredentials 的关联域名把自身和站点绑起来。用了非持久化数据存储做隐私模式，AutoFill 直接被挡。而即便自动填充能用，保存密码的弹窗在 WKWebView 里常常根本不触发，于是用户能填却存不下——和 Safari 体验正好相反。一个登录页是托管页的流量 App，是在逼用户每次都手动敲凭证。
runtime 的解法
宿主自有 runtime 不会把商家的表单丢上去、然后指望引擎和操作系统达成一致。它提供第一方输入层：它接管键盘与视觉视口的处理，让固定栏永不被遮；它跨引擎统一焦点与滚动行为；它预先处理输入法组字，让字符和光标正确落地；它提供一条受许、安全、绑定宿主自身凭证库的自动填充通道，而不是求每个商家页去接域名。表单变成平台担保的表面，而不是每页各赌一把。
| 维度 | WebView | 宿主自有 runtime |
|---|---|---|
| 键盘与布局 | 不缩放，固定栏被遮 | 视觉视口已接管，栏常显 |
| 焦点滚动 | 目标选错，字段跳走 | 跨引擎统一 |
| 输入法组字 | 掉字、光标冻结 | 预先处理，字符落地 |
| 自动填充 | 消失，保存弹窗缺失 | 第一方安全通道 |
| 谁拥有它 | 商家页，依赖引擎 | 平台担保的输入层 |
本系列的贯穿主线是控制权。WebView 让商家的表单上了你的 App，却把键盘、光标、输入法交给了两层之间一场谈不拢的谈判。runtime 让你自己掌握输入。对于一个目录里全是别人结账页的平台，这份掌握，就是成交与弃购之间的那条线。
参考来源
- WKWebView 坑：键盘不触发 resize、焦点滚动跳错 — iOS WebView 需接 Visual Viewport API；自动滚动可能藏起输入框。
- iOS WKWebView 自动填充需默认数据存储 + 关联域名 — 非持久化存储挡掉 AutoFill；需 webcredentials 绑定。
- WKWebView 密码自动填充：保存弹窗常常不触发 — 自动填充仅部分可用；密码保存 WebView 不支持。
- Android WebView 输入法组字 bug：掉字、光标冻结 — 受控输入与组字冲突；iOS WebView 更常见。
- Android WebView 语音输入组字带换行时丢首段 — 组字跨块边界时文字从未进 DOM。
