spellcheck在contenteditable区域是否默认开启？

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

contenteditable 元素的 spellcheck 默认值是 false

一个常见的误区是认为所有可编辑区域都会默认开启拼写检查。事实恰恰相反：浏览器对 contenteditable 区域默认禁用了拼写检查，即使开发者没有显式地写上 spellcheck 属性。这个行为，与 textarea 或 input[type="text"] 这些表单控件完全不同——后者在绝大多数浏览器里，通常都是默认开启检查的，效果等同于你写了 spellcheck="true"。

为什么 contenteditable 默认 spellcheck=“false”？

这背后其实有个很实际的技术考量。你想，一个 contenteditable 区域里能放的东西太“杂”了：可能是普通的段落文本，也可能是代码块、数据表格，甚至是嵌套着各种 HTML 标签的富媒体内容。对于浏览器来说，它很难也不应该去“猜”这里面到底全是自然语言，还是有别的特殊用途。因此，为了避免在不该出现的地方画上恼人的红色波浪线，或者弹出牛头不对马嘴的纠错建议，浏览器索性采取了最保守的策略：默认关闭。

• 这意味着，即使你简写成
  ，它在浏览器看来，也等同于
  。
• 只有当你明确写上 spellcheck="true" 时，检查功能才会被尝试启用。但请注意，这个“启用”也是有条件的，内容结构复杂时，它可能并不生效。
• 具体到各浏览器，你会发现 Chrome 和 Safari 对 contenteditable 的拼写检查支持比较“克制”； Firefox 相对积极一些，但其稳定性和表现依然无法与 textarea 这样的原生表单控件相提并论。

spellcheck=“true” 在 contenteditable 中的实际表现

那么问题来了：如果我主动开启了，是不是就能高枕无忧了呢？答案是否定的。就算你设置了 spellcheck="true"，浏览器也只会对其中纯粹的文本节点进行分析。而对于下面这些情况，它通常会选择忽略：

• 内部被 spellcheck="false" 属性显式包裹的子元素（例如一个用于展示API密钥的 标签）。
• 带有 user-select: none 样式或被设置为 readonly 的文本节点。
• 换行、空格或标点符号附近的单词边界，特别在中文、英文、数字混合输入的场景下，识别准确率会打个折扣。

来看个简单的例子：

。在这里，“test”这个单词可能会被检查，但包裹在 标签里的 “console.log()” 则几乎肯定不会被检查，而且浏览器也不会因此抛出任何错误。

容易忽略的兼容性坑

到了移动端，尤其是iOS系统，情况就更复杂了。基本上，iOS不会完全遵从 contenteditable 元素上的 spellcheck 属性。系统自带的输入法会接管大部分行为，并按照自己的规则进行高亮和纠错。这个时候你会发现：

• 设置 spellcheck="false" 可能根本不起作用。
• 要实现较为彻底的关闭，往往需要配合 autocorrect="off"、autocapitalize="none"、inputmode="text" 等多个属性组合使用。
• 在iOS Safari中还有一个“坑”：如果 contenteditable 的内容为空或者只有空白字符，它有时会退化为原生输入框的行为，从而意外地触发系统的拼写检查。

所以，经验表明，在那些对输入内容有严格控制的场景里——比如在线代码编辑器或者JSON数据输入区——最好不要把希望完全寄托在 spellcheck 这个属性上。一个更务实的建议是：优先考虑使用 contenteditable="plaintext-only"（尽管这是一个非标准属性，但部分前端框架会模拟实现它），或者，干脆降级使用 textarea 配合自定义的语法高亮方案，反而能获得更稳定、更可控的效果。