spellcheck="false"需设在真实接收输入的隐藏textarea上才生效，因专业编辑器用虚拟dom模拟输入，主渲染区不可编辑；直接设于容器或只读元素无效。
专业在线编辑器（如 VS Code Web、Monaco、CodeMirror 6）的 Web 版里，spellcheck 属性不能靠“设一次就全局生效”，它只对实际承载输入事件的可编辑节点起作用——而这类编辑器几乎都不用原生 contenteditable 或 textarea 渲染主编辑区，而是用覆盖层 + 虚拟 DOM 模拟输入。直接在容器上写 spellcheck="false" 大概率无效。
为什么 Monaco/CodeMirror 的 spellcheck="false" 看似不生效
这类编辑器把真实输入委托给一个隐藏的、透明的 textarea（Monaco 中常是 class="monaco-editor-background" 下的 textarea；CodeMirror 6 中是 role="textbox" 的 textarea），所有键盘事件都由它捕获，但视觉上不可见。你看到的代码高亮区域只是渲染层，不是可编辑元素。
- 你在
div#editor上设spellcheck="false"，浏览器根本不会检查它——它不可编辑 - 你在渲染出的
span或pre上设spellcheck="false"，同样无效——只读元素不响应该属性 - 必须找到那个真正接收
input和keydown的textarea节点，再对其设置spellcheck="false" - Monaco 可在
editor.onDidFocusEditorText后动态 patch；CodeMirror 6 推荐在view.dom插入后立即操作该textarea
textarea 是最可靠、最易控的 spellcheck 落点
如果你的编辑器是轻量级实现（比如用 textarea + CodeMirror 5 或简单语法高亮），那 spellcheck="false" 就是最直接有效的方案，且兼容性最好。
-
<textarea spellcheck="false" autocorrect="off" autocapitalize="none" inputmode="verbatim"></textarea>组合在 Chrome、Firefox、Edge 上能彻底屏蔽波浪线和右键建议 - Safari（尤其 macOS/iOS）仍可能有约 200ms 的短暂下划线残留，这是其异步词典检查机制导致，并非属性失效
- 别给
input[type="text"]设spellcheck="false"——浏览器基本忽略它，这不是 bug，是规范限制 - 移动端 iOS Safari 中，
autocorrect="off"的优先级高于spellcheck，漏写就等于白设
contenteditable 编辑器里 spellcheck 的继承陷阱
富文本编辑器（如 Slate、Draft.js、自研 contenteditable 容器）中，spellcheck 不继承，也不传播到动态插入的子节点——新粘贴进来的 span、strong 或用户按回车生成的 p 默认无该属性，拼写检查会静默恢复。
- 父级
div[contenteditable="true"][spellcheck="false"]只影响自身，不影响内部未显式声明的子元素 - 监听
input或DOMSubtreeModified（或更现代的MutationObserver）来动态补上spellcheck="false"是必要手段 - Safari 对
contenteditable的spellcheck支持最弱，即使属性存在，也可能完全不画波浪线——别把它当跨浏览器一致行为依赖 - 若编辑器支持内嵌只读块（如代码块、引用块），这些区域本身不可编辑，加
spellcheck无意义；但它们包裹的可编辑子容器（如div[contenteditable="true"]）必须单独控制
真正难的不是加属性，而是识别哪个 DOM 节点在承担输入职责。很多编辑器在初始化后才动态挂载 textarea，或在焦点切换时替换输入代理——这意味着 spellcheck="false" 必须在正确时机、正确节点上设置，晚了或错了，红线就会冒出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
