spellcheck属性仅控制拼写提示显示，不提升准确性；仅对type="text"/"search"的input、textarea和contenteditable元素有效，其他输入类型及非编辑元素无效。
spellcheck 属性不能提升输入准确性，它只控制红色波浪线是否出现；想靠它防错字、拦提交、校验语义，从设计上就走偏了。
哪些元素加 spellcheck 才真起作用
只有三类可编辑元素会响应该属性：
-
<input type="text">和<input type="search">—— 最可靠，显式写spellcheck="true"或spellcheck="false"都能被 Chrome/Firefox/Edge 正确识别 -
<textarea>—— 支持最一致，所有主流浏览器都认，推荐作为拼写开关的首选载体 - 设置了
contenteditable="true"的元素（如<div contenteditable="true">）—— 必须同时显式声明spellcheck="true"，否则默认关闭；且不继承父级，子节点需单独加
以下写法完全无效：
-
<input type="email">、<input type="url">、<input type="tel">：浏览器优先执行格式校验，拼写检查常被跳过 -
<input type="password">、<input type="number">、<input type="date">：DOM 解析时就被静默丢弃，加了也白加 -
<p>、<span>、<div>（未设contenteditable）：不可编辑，属性被浏览器忽略
spellcheck="false" 为什么还标红线
这不是属性失效，而是其他机制在底层覆盖了拼写提示：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 中，
autocorrect="off"会直接压制拼写逻辑，此时spellcheck="false"形同虚设 - 系统级拼写开关未开启：macOS 需勾选「系统设置 → 键盘 → 文本输入 → 在网页文本框中检查拼写」；Windows/Chrome 需在
chrome://settings/languages中启用并安装 English (US) 词典 - 输入法处于中文模式：哪怕你打的是英文单词，搜狗、微软拼音等会拦截拼写反馈；必须切到纯英文直输（如按 Shift）再试
-
inputmode="numeric"或inputmode="tel"会让系统键盘跳过拼写逻辑，spellcheck失去作用对象
真正要禁用干扰，得组合四件套：spellcheck="false" + autocorrect="off" + autocapitalize="none" + inputmode="verbatim"。漏一个，比如只关 spellcheck，用户输 sk_live_abc123 仍可能看到 sk 被标红。
动态控制 spellcheck 的坑点
用 JavaScript 切换状态看似简单，但有三个关键细节容易翻车：
- 用
el.spellcheck = false，别用el.setAttribute('spellcheck', 'false')—— 后者在部分浏览器中不触发重绘 - 已聚焦的输入框不会立即清除下划红线，需先
el.blur()，再设值，最后el.focus()才能刷新显示 - 别在
input事件里频繁切换 —— 会导致光标跳动、输入卡顿，尤其在移动端
批量开关表单时，别只改父容器，必须精准作用于每个节点：document.querySelectorAll('textarea, input[type="text"]') 获取目标，逐个赋值。若表单含动态插入字段，插入后得手动初始化 spellcheck 值。
移动端 spellcheck 基本不可控
iOS 和 Android 的原生键盘行为差异大，spellcheck 属性本身对它们影响极小：
- iOS Safari：不渲染波浪线，仅依赖软键盘自身纠错；
spellcheck="true"几乎无感，spellcheck="false"单独使用基本无效 - Android Chrome：略好些，但若系统键盘开启了拼写检查，照样自己标红线 —— 这跟
spellcheck无关，是原生行为
富文本编辑器（如 Monaco、CodeMirror）更麻烦：真实输入层通常是隐藏的 <textarea>，而你看到的编辑区是 div 渲染的 —— spellcheck 得挂到那个隐藏 textarea 上，不是挂到外层容器。这点最容易被忽略，一查 DOM 就明白。
