html 中没有 virtualkeyboardpolicy 属性，它不属于标准，所有主流浏览器均未实现；真正可控的是 inputmode、enterkeyhint 和焦点滚动等已有机制。
HTML 中没有 virtualkeyboardpolicy 全局属性，它不是标准属性，也不能用于“高定制输入框”的任何实际控制。 所有主流浏览器（Chrome、Safari、Firefox）均未实现该属性，W3C 规范、MDN 文档、Chromium 和 WebKit 源码中均无定义。所谓“妙用”是建立在误解之上的伪需求。
为什么你在代码里写 virtualkeyboardpolicy 完全没反应
这不是兼容性问题，而是该属性根本不存在于 HTML 标准中。你看到的可能是以下几种混淆：
-
inputmode：仅向系统提示键盘类型（如inputmode="decimal"），不控制弹出时机或覆盖行为 -
enterkeyhint：只改回车键文案（search/send），不影响键盘是否出现 -
autofocus：页面加载时尝试聚焦，但移动端多数浏览器会静默忽略，且不触发键盘 - Chromium 曾实验性支持
navigator.virtualKeyboard.show()，但已在 Chrome 125+ 中移除，且从不接受virtualkeyboardpolicy字符串作为参数
想让输入框“高定制”，真正起作用的其实是这三件事
所谓高定制，本质是控制键盘类型、回车行为、焦点后布局响应——而这些都靠已有标准属性和事件链配合：
-
inputmode+type组合决定键盘形态：比如<input type="search" inputmode="latin" enterkeyhint="search">在 Android 上更大概率唤起带搜索图标的键盘 -
enterkeyhint="go"或"next"能影响软键盘右下角按钮文字，提升操作直觉，但需搭配type="url"或type="text"才稳定生效 - 焦点后滚动必须手动干预：
input.addEventListener('focus', () => input.scrollIntoView({ block: 'nearest', behavior: 'smooth' }))，否则 iOS Safari 常卡在底部被遮挡 - 避免用
tabindex="-1"或inert封锁输入框父容器——它们会直接阻断 focus 链，导致用户点击后毫无反应
别碰 inert + 键盘弹出这个组合
当 inert 用在包含输入框的区域外层时，虚拟键盘展开/收起过程会触发浏览器内部状态紊乱：
- iOS Safari 下，键盘收起后
inert可能未正确解绑，导致背景区域持续不可点 - Android WebView 中，
inert与visualViewport.resize事件存在竞态，造成输入框定位错乱 - 修复思路不是“绕过”，而是换策略：用
pointer-events: none+opacity: 0.5视觉禁用，保留事件穿透能力；或只对非表单区域动态添加inert，避开input、textarea父链
最易被忽略的一点：键盘是否弹出，完全由用户手势上下文 + 元素可聚焦性共同决定。任何脱离 click/touchend 同步调用 .focus() 的逻辑（包括 setTimeout、Promise.then、requestAnimationFrame）在 iOS Safari 上基本失效——这不是 bug，是设计使然。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
