spellcheck="false"仅对textarea和contenteditable="true"元素生效；input[type="text"]等单行输入框不支持该属性，常被浏览器忽略。
spellcheck="false" 在 textarea 和 contenteditable 元素上才生效
浏览器原生拼写检查只作用于可编辑的文本区域，input[type="text"]、input[type="search"] 等单行输入框不支持 spellcheck 属性（即使写了也常被忽略）。真正起效的是：textarea 和设置了 contenteditable="true" 的元素（比如代码编辑器常用的 div 或 pre 包裹容器）。
常见错误是给 pre 或 code 标签加 spellcheck="false"——它们默认不可编辑，该属性完全无效。
- ✅ 正确做法：在编辑器根容器（如
div#editor）上设置contenteditable="true"和spellcheck="false" - ✅ 若用
textarea实现简易编辑器，直接加spellcheck="false"即可 - ❌ 错误做法：对只读的
code块或渲染后的预览区设置spellcheck
Chrome 和 Safari 对 spellcheck="false" 的兼容性差异
Chrome 从较早版本就稳定支持 spellcheck="false"，但 Safari（尤其 macOS 13+ 和 iOS 16+）存在一个关键限制：如果系统「自动拼写更正」开关开启，且元素获得焦点，Safari 仍可能短暂显示下划线（约 200ms 后消失），并非 bug，而是其异步词典检查机制导致。
这不是属性失效，而是行为延迟。要彻底规避，需配合其他手段：
- 在
contenteditable元素上额外加autocomplete="off"和autocorrect="off"（iOS Safari 更认后者） - 避免使用
inputmode="text"—— 它会主动唤起带拼写建议的键盘，和spellcheck冲突 - 某些 Electron 应用中，还需在 WebPreferences 里禁用
spellcheck: false（这是主进程级控制，和 HTML 属性无关）
Monaco、CodeMirror 等编辑器为何 spellcheck="false" 不起作用？
这类编辑器通常把用户输入层（如 textarea）设为透明覆盖在真实编辑区域之上，用于捕获输入事件，但视觉上不可见；而真正显示代码的是多个绝对定位的 div + canvas 或 span 组合。此时你看到的“编辑区”本身不是可编辑元素，spellcheck 自然没地方挂。
解决路径很明确：找到那个实际承载输入事件的隐藏 textarea（Monaco 里常是 class="monaco-editor-background" 下的 textarea；CodeMirror 6 中是 role="textbox" 的 textarea），然后对其设置 spellcheck="false"。
- Monaco：可通过
editor.addOverlayWidget或初始化时 patch DOM，但更稳妥的是在editor.onDidFocusEditorText后动态设置 - CodeMirror 6：在
view.dom插入后，用view.contentDOM.querySelector('textarea')获取并修改 - 别试图对 editor root div 设置
spellcheck—— 它不处理输入，只是容器
spellcheck="false" 不影响语法高亮或语言服务
这个属性只关闭浏览器内置的拼写词典检查（即红色波浪线），和编辑器自身的语法校验、LSP 提示、括号匹配、错误诊断完全无关。有人误以为关掉它会让 ESLint 或 Prettier 失效，其实不会。
真正容易混淆的是：某些编辑器（如早期 VS Code Web 版）在启用「代码操作建议」时，会把变量名误判为拼写错误（比如 userNamme 被标红），这其实是 LSP 返回的语义错误，不是浏览器拼写检查。这时候关 spellcheck 没用，得查 language server 配置或重命名变量。
记住一点：只要波浪线是红色细线、右键有「拼写建议」菜单，才是浏览器干的；如果是灰色/绿色粗线、右键显示「快速修复」「查看问题」，那就是编辑器自己的逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
