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的文本节点。 - 换行符、空格或标点符号附近的单词边界，尤其在中文、英文、数字混合输入的场景下，识别准确率会显著下降。
举例说明： This is a test. console.log() 标签内的 “console.log()” 则几乎肯定不会被检查，且浏览器不会因此抛出任何错误提示。
容易忽略的兼容性坑
在移动端，尤其是 iOS 系统中，情况更为复杂。iOS 通常不会完全遵循 contenteditable 元素上的 spellcheck 属性设置。系统自带的输入法会接管大部分行为，并按照其内部规则进行高亮和纠错。此时可能出现以下问题：
- 设置
spellcheck="false"可能完全无效。 - 要实现彻底关闭拼写检查，往往需要组合使用
autocorrect="off"、autocapitalize="none"、inputmode="text"等多个属性。 - iOS Safari 中还存在一个特定问题：如果
contenteditable的内容为空或仅包含空白字符，它有时会退化为原生输入框的行为，从而意外触发系统的拼写检查功能。
因此，在需要对输入内容进行严格控制的场景中——例如在线代码编辑器或 JSON 数据输入区——不建议完全依赖 spellcheck 属性。更务实的解决方案是：优先考虑使用 contenteditable="plaintext-only"（尽管这是一个非标准属性，但部分前端框架会模拟其行为），或者直接降级使用 textarea 并配合自定义的语法高亮方案，以获得更稳定、更可控的编辑体验。
