spellcheck属性仅是提示浏览器是否对可编辑元素启用原生拼写高亮，实际生效需满足三类元素（text/search/url/tel/email输入框、textarea、contenteditable元素）、浏览器支持、系统词典启用及无冲突属性（如autocorrect）等条件。
spellcheck 属性不能“开启拼写检查功能”，它只是向浏览器发出一个提示：允许/禁止对这个可编辑元素的内容做原生拼写高亮。是否真画出红色波浪线，取决于浏览器实现、系统词典、输入法状态和配套属性是否冲突。
哪些元素加了 spellcheck 才会真正响应
只有三类元素可能触发拼写检查：
-
<input type="text">、<input type="search">、<input type="url">、<input type="tel">、<input type="email">（type="password"无效） -
<textarea>（最稳定，各浏览器基本都支持） - 设置了
contenteditable="true"的任意元素，如<div contenteditable="true">、<p contenteditable="true">（注意：contenteditable不继承，子元素需单独设spellcheck）
常见误用：<span spellcheck="true">、<p spellcheck="true"> —— 这些不可编辑，属性被浏览器静默忽略。
spellcheck="false" 为什么经常失效
根本原因不是 spellcheck 没写对，而是其他属性在底层覆盖了拼写逻辑：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- iOS Safari 中，
autocorrect="off"会直接禁用拼写建议，哪怕spellcheck="true"也无反应 -
inputmode="numeric"或inputmode="tel"会让系统键盘跳过拼写检查，spellcheck形同虚设 - 父元素设了
spellcheck="false"，子元素会继承 —— 容易漏查 - 某些旧版 Chrome 在
autocomplete="off"下连带抑制校验行为
要真正关闭拼写干扰，推荐组合设置：spellcheck="false" + autocorrect="off" + autocapitalize="none"。
怎么验证 spellcheck 是否在真实工作
不能只看 HTML 里有没有那个属性，得观察运行时反馈：
- 在支持的输入框中输入明显错词（如
recieve），看是否有红色波浪线（Chrome/Edge 通常有，Firefox 需确认layout.spellcheckDefault设为1） - 右键点击错词，检查上下文菜单是否出现“更正为…”或“添加到字典”选项
- 排除干扰：临时换一个干净的
<textarea spellcheck="true">，输入helo测试；若仍无反应，问题大概率出在系统级设置（如 macOS 键盘设置未勾选“在网页文本框中检查拼写”）或输入法处于中文模式
移动端几乎不可靠：iOS Safari 和 Android Chrome 均不渲染波浪线，仅依赖原生键盘纠错，spellcheck 属性本身对它们影响极小。
React/Vue 中设置 spellcheck 的坑
框架不会自动修正大小写或布尔序列化，容易出错：
- React 中必须用小写
spellcheck（不是spellCheck），且传布尔值：<textarea spellcheck={true}>；传字符串"true"在 SSR 场景下可能被错误序列化 - Vue 模板中写
spellcheck="true"即可；若用绑定语法，需写:spellcheck="true"（注意冒号） - 所有框架都不处理
contenteditable元素的 spellcheck 继承问题 —— 子节点仍需显式声明
真正需要稳定拼写控制的场景（比如富文本编辑器、多语言表单、离线应用），别依赖 spellcheck。它只是个提示属性，浏览器有权忽略，也不触发任何事件。WebAssembly 拼写库（如 tiny-spellchecker）才是可控方案。
