textarea是唯一可靠支持spellcheck属性的多行文本编辑器载体，必须直接设在标签上且显式声明true/false；移动端需配合autocorrect="off"，失效主因包括系统拼写开关、中文输入法及企业策略。
textarea 是 spellcheck 唯一靠谱的载体
多行文本编辑器场景下，textarea 是唯一能稳定响应 spellcheck 属性的 HTML 元素。所有主流浏览器（Chrome、Firefox、Safari、Edge）都认可它，而 div[contenteditable="true"] 在 Safari 上常被忽略，input[type="text"] 即使加了 rows 伪多行也大概率失效。
常见错误是把 spellcheck="false" 加在父容器或富文本外层 div 上——那只是装饰，浏览器根本不会去检查它。必须直接作用于 textarea 标签本身。
-
textarea默认不启用拼写检查，必须显式写spellcheck="true"或spellcheck="false" - 移动端 iOS Safari 会优先响应
autocorrect="off"，若只设spellcheck="false"而没配这个，仍可能自动修正单词 - 输入后需松开空格或回车才触发标红，不是实时逐字检测
spellcheck="false" 失效的三个真实原因
你在 textarea 上写了 spellcheck="false" 却仍看到红色波浪线？不是代码错了，而是以下任一条件未满足：
- 系统级拼写开关开着：macOS 要关掉「系统设置 → 键盘 → 文本输入 → 在网页文本框中检查拼写」；Windows/Chrome 需进
chrome://settings/languages确认词典未强制启用 - 输入法处于中文模式：哪怕你打的是英文，搜狗、微软拼音等会拦截拼写反馈；切换为纯英文直输（如按 Shift）再试
- 企业策略禁用：公司部署的 Chrome/Edge 可能通过组策略全局关闭拼写服务；可用个人账号开隐身窗口验证是否真被策略压制
验证是否生效，不能只看 HTML 源码，得输一个明显错词（比如 recieve），观察：是否有红色波浪线；右键点击是否出现“更正为…”菜单项。两者皆无才算成功。
动态开关 spellcheck 的安全写法
用 JavaScript 切换 spellcheck 状态时，直接改 element.setAttribute('spellcheck', 'false') 会有延迟：已聚焦的 textarea 不会立刻清除波浪线，得先失焦再聚焦才刷新。
稳妥做法是配合焦点控制：
- 先调用
element.blur() - 再设
element.setAttribute('spellcheck', 'false') - 最后调用
element.focus()
避免在 input 事件里频繁切换——会导致光标跳动、输入卡顿。也不要依赖 getComputedStyle 判断状态，因为 spellcheck 是 HTML 属性，不是 CSS 可计算样式。
别碰 contenteditable 的 spellcheck 继承逻辑
如果用 div[contenteditable="true"] 实现多行编辑（比如简易富文本），请放弃对 spellcheck 的精细控制。它的继承行为极不可靠：
- 父元素设了
spellcheck="false"，子<p></p>或<span></span>不会自动继承，必须每个可编辑子节点都显式声明 - Safari（尤其 macOS）常完全忽略
contenteditable区域的spellcheck设置 -
<pre class="brush:php;toolbar:false;"></pre>或<code>标签默认不可编辑，加spellcheck="false"完全无效
真正需要结构化输入（如 JSON/YAML/HTML 片段）时，直接用 textarea + 四件套：spellcheck="false" autocorrect="off" autocapitalize="none" inputmode="verbatim"，这是目前最可控、兼容性最好的路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
