spellcheck属性是提示性属性，仅控制浏览器是否显示红色波浪线，不阻止提交、不触发事件、不修正文字；仅对可编辑元素生效，如text/search/email/url/tel类input、textarea及contenteditable="true"的div/p，且需注意浏览器默认行为、属性覆盖及移动端限制。
spellcheck 属性不是“开关”，而是“提示”——它只影响浏览器是否画红色波浪线，不阻止提交、不触发事件、也不修正文字。
哪些元素加 spellcheck 才真起作用
只有可编辑且被浏览器认定为“适合拼写检查”的元素才响应该属性：
-
input类型必须是text、search、email、url、tel；password、number、date等类型即使设了spellcheck="true"也基本无效 -
textarea是最稳定的支持者，各浏览器都认，设spellcheck="false"后波浪线通常立即消失 -
contenteditable="true"的div或p需显式加spellcheck="true"（默认不启用），且子元素不自动继承，得单独写 -
span、p（没设contenteditable）、label等只读元素加了也白加
spellcheck="false" 为什么还标红？常见覆盖原因
波浪线没消失，大概率不是 spellcheck 失效，而是其他属性或系统行为在“抢答”：
- iOS Safari 中，
autocorrect="off"会直接压制拼写建议，此时spellcheck="false"形同虚设；必须三件套齐上：spellcheck="false"+autocorrect="off"+autocapitalize="none" -
inputmode="numeric"或inputmode="tel"会让系统键盘跳过拼写逻辑，spellcheck自然无从生效 - 父级元素设了
spellcheck="false"，子元素会继承——容易漏查，尤其在富文本编辑器嵌套结构里 - Chrome 和 Edge 对
input[type="text"]默认开启拼写检查，但 Firefox 用户需手动在about:config中把layout.spellcheckDefault设为1才能看到效果
禁用 spellcheck 的真实理由：防误报，不是防错字
你不需要关掉拼写检查来“防止用户输错”，而是要避免它把不该标的内容标红：
- IP 地址（如
192.168.0.1）被当单词标红 - API key（如
sk_live_abc123）里的sk、live被误判为拼写错误 - 代码片段（如
const foo = () => {}）中const在某些浏览器下触发红线 - 用户名、token、base64 字符串、医学术语等，浏览器词典根本覆盖不到
这种场景下，spellcheck="false" 是最轻量、最直接的干预方式，比用 CSS 隐藏波浪线（text-decoration: none 不起作用）或 JS 拦截更可靠。
移动端和富文本里的特殊表现
别指望 spellcheck 在手机上行为一致：
- iOS Safari 几乎忽略
spellcheck，是否显示建议完全由系统键盘设置和autocorrect控制 - Android Chrome 响应较弱，用户得先在系统设置里打开“拼写检查”，否则前端属性再全也没用
-
contenteditable容器里，Chrome 默认激进检查（连 HTML 标签名都可能标红），Safari 则常静默；若需强控，建议用div contenteditable="true" spellcheck="false"显式声明 - 混合应用（Cordova / Capacitor）中，WebView 可能完全忽略该属性，需检查
WebView.setWebContentsDebuggingEnabled等环境配置
真正需要稳定拼写校验的场景（比如支持多语言、离线、自定义词典），spellcheck 就不该是主力——WebAssembly 拼写库（如 tiny-spellchecker）才是可控方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
