spellcheck属性在移动端“存在但不可靠”，受系统键盘策略、webview差异及autocorrect等配套属性覆盖；ios中autocorrect="off"会彻底屏蔽拼写建议，android下inputmode="numeric"等会忽略spellcheck，微信/qq webview支持极弱，email/url类型默认禁用。
spellcheck 属性在移动端浏览器中“存在但不可靠”——它会被系统键盘策略、WebView 实现差异和配套属性覆盖，不能当作稳定开关使用。
哪些移动端场景 spellcheck 会直接失效
不是所有写了 spellcheck="true" 的输入框都能看到波浪线或右键建议：
- iOS Safari 中，
autocorrect="off"会彻底屏蔽拼写建议，哪怕spellcheck="true"也无效 - Android Chrome 某些版本下，
inputmode="numeric"或inputmode="tel"会让系统键盘跳过拼写检查逻辑，spellcheck被忽略 - 微信内置 WebView、QQ 浏览器 X5 内核等常见嵌入式环境，对
spellcheck支持极弱，甚至完全不渲染波浪线 -
type="email"和type="url"在多数移动浏览器中默认禁用拼写检查，这是规范行为，不是 bug
怎么验证 spellcheck 是否真生效
别只看 HTML 属性是否写了，要观察实际反馈：
- 在可编辑区域（如
textarea或contenteditable="true"的div）里输入明显错词（如 “recieve”），看是否有红色波浪线 - 长按文本，检查右键/上下文菜单中是否出现“更正为…”或拼写建议项
- 注意：iOS 上需确保系统设置 → 通用 → 键盘 → “拼写检查”已开启；Android 则依赖 Gboard 或三星键盘的“自动更正”开关
- 若波浪线不出现，但右键有建议，说明浏览器启用了底层校验但 UI 渲染被抑制 —— 这种情况
spellcheck其实“部分生效”
移动端稳定关闭拼写检查的组合写法
单靠 spellcheck="false" 几乎没用，必须协同控制输入行为：
- 显式关闭三件套：
spellcheck="false" autocorrect="off" autocapitalize="none" - 避免触发系统拼写逻辑的类型：不用
type="text"，改用type="search"或inputmode="text"（但注意后者仍可能唤醒键盘拼写） - 富文本编辑器里，父级
div[contenteditable]设了spellcheck="false"，子节点span即使设spellcheck="true"也会被继承压制 —— 需逐层检查 DOM 结构
最常被忽略的一点：移动端拼写检查本质是“系统键盘能力 + 浏览器桥接”的混合行为，spellcheck 只是提示信号，不是强制指令。真正需要强控时，得用 WebAssembly 拼写库（比如 tiny-spellchecker）自己接管校验逻辑。
