textarea是spellcheck最可靠的载体，monaco/codemirror等编辑器需精准操作隐藏textarea（如class="monaco-editor-background"或role="textbox"），而非外层容器；input[type]多数不响应spellcheck，contenteditable行为不可靠，禁用拼写检查须组合spellcheck="false"、autocorrect="off"、autocapitalize="none"、inputmode="verbatim"四属性。
textarea 是 spellcheck 控制最可靠的载体
在线 IDE（比如 Monaco、CodeMirror）里想关掉拼写检查，别在 pre 或 code 标签上瞎试——它们默认不可编辑，spellcheck="false" 直接被忽略。真实输入层几乎总是隐藏的 textarea：Monaco 里常见于 class="monaco-editor-background" 下的那个；CodeMirror 6 则是 role="textbox" 的 textarea。它才是浏览器拼写引擎真正作用的对象。
所以关键动作不是“给编辑器容器设属性”，而是定位并操作那个真实 textarea：
- Monaco：用
editor.onDidFocusEditorText监听焦点后动态设置textarea.spellcheck = false，或初始化完成后再 patch DOM - CodeMirror 6：等
view.dom插入文档后，通过视图实例v找到内部textarea并赋值 - 别依赖 CSS 选择器硬查，优先用编辑器 API 提供的 DOM 引用路径
input[type="text"] 等表单控件对 spellcheck 基本不响应
input[type="email"]、input[type="url"]、input[type="tel"] 这类控件，浏览器优先执行格式校验（比如邮箱正则），拼写检查逻辑被跳过，spellcheck="false" 写了也白写。
input[type="password"]、input[type="number"]、input[type="date"] 更彻底：DOM 解析阶段就静默丢弃该属性，连监听都无从谈起。
唯一稳定支持 spellcheck 的原生可编辑元素只有：textarea 和 div[contenteditable="true"]。但后者问题太多，见下一条。
contenteditable 区域 spellcheck 行为极不可靠
富文本编辑器若基于 div[contenteditable="true"] 实现，spellcheck="false" 几乎无法保证生效：
- Safari（尤其 macOS）常无视该设置，系统级拼写检查开关（「键盘 → 文本输入 → 在网页文本框中检查拼写」）一开，所有
contenteditable全线沦陷 - 父元素设了
spellcheck="false"，子节点不会自动继承；必须每个p、span都显式声明，且仍可能因浏览器实现差异失效 - 右键菜单里的“更正为…”项在某些版本 Safari 中仍会弹出，哪怕 DOM 上已写死
spellcheck="false"
结论很直接：写代码、JSON、YAML、HTML 片段这类结构化文本，别碰 contenteditable 的拼写控制，绕开它比修复它更省时间。
四件套组合才能真正压制 iOS/macOS 拼写干扰
textarea 里写了 spellcheck="false" 还标红？不是属性错了，而是被 iOS Safari 的 autocorrect="off" 抢先接管了拼写逻辑——此时 spellcheck 形同虚设。macOS 系统级设置未关闭也会让所有属性失效。
验证是否真生效，不能只看 HTML 源码，得在浏览器里输一个明显错词（比如 recieve），观察两件事：
- 有没有红色波浪线
- 右键点击是否出现“更正为…”菜单项
两者皆无才算成功。为此必须组合使用四件套：
spellcheck="false"autocorrect="off"autocapitalize="none"inputmode="verbatim"
漏掉任意一项，在特定平台或系统设置下都可能失效。尤其是 inputmode="verbatim"，它明确告诉浏览器“这是纯文本输入”，能有效抑制移动端智能输入法的干预。
