inputmode 属性跨端兼容性差且行为边界明确：ios safari 16.4+ 仅支持部分值，android chrome 支持较全但国产浏览器常忽略；必须搭配 type="text" 使用，且需协同 autocorrect 等属性避免干扰。
不一致，而且差异非常具体——不是“有时有效有时无效”，而是“哪些值在哪个系统上起什么作用”有明确边界。
inputmode="numeric" 在 iOS 和 Android 上的实际效果
iOS Safari 直到 16.4 才开始支持 inputmode，且仅支持 numeric、decimal、tel、email、text 这几个值；其中 inputmode="numeric" 在 iOS 上能稳定唤起数字键盘（无小数点），但 inputmode="decimal" 仍大概率弹出全键盘。Android Chrome 82+ 支持完整值集，但国产浏览器（如微信 X5 内核、QQ 浏览器）基本忽略该属性，即使写了也等同于没写。
- 必须搭配
type="text"使用——type="number"会直接覆盖inputmode行为 -
inputmode="tel"是目前跨端兼容性最好的选择，iOS/Android 均能稳定触发数字键盘（带 *# 键） - 不要依赖
inputmode做格式校验，它只影响键盘类型，不干预 value 解析或提交逻辑
为什么 inputmode="search" 或 inputmode="url" 在 iOS 上没反应
因为 iOS Safari 根本不识别这两个值。官方支持列表里没有它们，写了等于白写。Android Chrome 虽然识别，但实际唤起的键盘和 inputmode="text" 几乎一样，右下角按钮文字（如「搜索」「前往」）也常被系统忽略或强制替换为「完成」。
- 想让 iOS 键盘右下角显示「搜索」，唯一可靠方式是
type="search"+enterkeyhint="search" -
enterkeyhint在 iOS 16.4+ 和 Android Chrome 77+ 支持较好，但旧安卓机（尤其 WebView 内核）仍可能显示「换行」 - 如果业务强依赖搜索触发型交互，建议监听
keydown事件捕获 Enter 键，而非信任键盘按钮文案
inputmode 配合 autocorrect 等属性的协同陷阱
inputmode 只管键盘类型，但键盘行为还受 autocapitalize、autocorrect、spellcheck 干预。比如在 iOS 上，即使写了 inputmode="numeric"，若没加 autocapitalize="none" autocorrect="off" spellcheck="false"，某些输入法仍可能自动补全或大写首字母（尤其当用户切换过中英文）。
- 密码类输入务必用
inputmode="text"+type="text"+ CSS 遮盖，而不是type="password"—— 后者在部分安卓 ROM 上会被安全输入法劫持，导致input事件延迟或丢失 - 国产安卓机（如华为 EMUI、小米 MIUI）常对
type="password"强制弹出自定义安全键盘，此时inputmode完全失效 - 所有含数字输入场景，优先测真机：iOS 16.4+、Android Chrome 最新版、微信内置浏览器（X5）、企业微信 WebView
最易被忽略的一点：软键盘弹起后页面布局位移，在 iOS 上靠 viewport 的 height=device-height 配合 resize 事件还能微调；但在安卓 WebView 里，visualViewport 支持极差，很多机型连键盘高度都拿不准——这时候 inputmode 写得再准，用户也可能因遮挡而无法完成输入。
