contenteditable 元素的 spellcheck 默认值为 false，因语义开放、内容不确定，浏览器保守禁用拼写检查；显式设为 true 也仅对纯文本节点生效，且在移动端尤其 iOS 上兼容性差。

contenteditable 元素的 spellcheck 默认值是 false

浏览器对 contenteditable 区域默认禁用拼写检查，哪怕你没写 spellcheck 属性。这和 textarea 或 input[type="text"] 不同——后两者在多数浏览器中默认开启（即行为等价于 spellcheck="true"）。

为什么 contenteditable 默认 spellcheck="false"？

因为可编辑区域的语义更开放：可能是富文本、代码块、表格、甚至嵌套 HTML 片段。浏览器无法安全假设其中全是自然语言文本，所以保守地关闭拼写检查，避免误标红线或弹出干扰建议。

• 即使你写了
  ，它也等价于
• 显式设为 spellcheck="true" 才会启用（但效果仍受限于内容结构，比如内联 里混着 HTML 标签时可能不生效）
• Chrome 和 Safari 对 contenteditable 的拼写检查支持较弱；Firefox 相对积极，但仍不如原生表单控件稳定

spellcheck="true" 在 contenteditable 中的实际表现

就算你主动开启，也不等于“全量检查”。浏览器只对纯文本节点（Text 类型）做拼写分析，且会跳过：

Verse

Verse是由印象笔记团队推出的 AI 写作与文档工具。

下载

• 被 spellcheck="false" 显式包裹的子元素（如 API_KEY_123）
• 含 style="user-select: none" 或 readonly 的文本节点
• 换行符、空格、标点符号周围的单词边界识别不准，尤其在多语言混合场景下

示例：

This is a test. console.log()

—— “test” 可能被检查，“console.log()” 不会被检查，也不会报错。

容易忽略的兼容性坑

移动端（尤其是 iOS）基本不响应 contenteditable 上的 spellcheck 属性，系统级输入法直接接管并按自身规则高亮/纠错，此时：

• spellcheck="false" 几乎无效
• 必须配合 autocorrect="off"、autocapitalize="none"、inputmode="text" 等组合使用
• iOS Safari 中，若 contenteditable 内容为空或只有空白字符，有时会退化为原生输入框行为，意外触发拼写检查

真正需要强控制的场景（如代码编辑器、JSON 输入区），别依赖 spellcheck，应优先用 contenteditable="plaintext-only"（非标准，但部分框架模拟）或降级为 textarea + 自定义高亮。