spellcheck 属性对 input[type="text"] 无效，标红由系统自动更正或 os 拼写设置触发；textarea 和 contenteditable 才可靠支持 spellcheck，禁用需组合 spellcheck="false"、autocorrect="off"、autocapitalize="none"。
spellcheck 属性对 <input type="text"> 的控制能力非常有限——它在大多数浏览器中**不生效**，尤其在 Chrome、Firefox 和 Safari 中，即使显式写 spellcheck="false"，仍可能出现红色波浪线。这不是 bug，而是规范与实现的共识：表单控件的拼写/纠错行为由操作系统输入法或浏览器 UI 层驱动，而非 DOM 属性。
为什么 input 上设 spellcheck="false" 还是标红？
红线通常不是拼写检查（spellcheck）触发的，而是系统级自动更正（autocorrect）或键盘行为导致的：
- iOS Safari 中，
autocorrect="off"会直接压制所有拼写建议和红线；仅设spellcheck="false"完全无效 - macOS 系统设置里若开启「在网页文本框中检查拼写」，Chrome 会绕过
spellcheck属性强制加线 -
inputmode="numeric"或inputmode="tel"会让键盘跳过拼写逻辑，此时spellcheck形同虚设 - 父容器设了
spellcheck="false"，子input不继承——但这也无关紧要，因为input本就不响应它
textarea 和 contenteditable 才是 spellcheck 的可靠作用域
这两个场景下，spellcheck 行为稳定、可预测：
-
<textarea spellcheck="false"></textarea>在 Chrome/Firefox/Edge 中基本都能立即移除波浪线和右键拼写菜单 <div contenteditable="true" spellcheck="false"> 必须显式声明 <code>spellcheck，否则多数浏览器默认关闭（即等效于false），但不写就不可控- 子元素不继承：
<p contenteditable spellcheck="true"><span>hello</span></p>中的span需单独加spellcheck="true" -
contenteditable元素若被user-select: none或pointer-events: none干扰，可能破坏编辑态，导致波浪线不渲染 -
spellcheck="false"：提示浏览器别启动拼写检查逻辑 -
autocorrect="off"：iOS 必需项，禁用系统自动更正（否则照样标红+弹“更正为…”） -
autocapitalize="none"：防止首字母意外大写（常伴随autocorrect激活） - 额外建议：
inputmode="verbatim"（非标准但 Chrome/Safari 支持）明确提示键盘用纯文本模式，对代码、token、base64 等场景最稳妥
真正想禁用“标红+弹建议”，得组合写属性
单靠 spellcheck="false" 在移动端尤其 iOS 上等于没写。必须三件套齐上：
别指望 spellcheck 控制输入逻辑或替代校验——它只管画不画那条红线，且这条线本身在 input 上就不可靠。真要一致禁用干扰，优先选 textarea 或 contenteditable + 组合属性，再配合系统级拼写开关排查。
