contenteditable 元素需显式设置 spellcheck="true" 才启用拼写检查，子元素不继承该属性，safari 支持最弱；代码编辑推荐 textarea + spellcheck="false"、autocorrect="off"、autocapitalize="none"、inputmode="verbatim" 组合。
contenteditable 元素加 spellcheck="true" 为什么没红线
不是 spellcheck 属性没写对，而是富文本容器本身默认不启用拼写检查——contenteditable="true" 的 div 或 p 必须显式加 spellcheck="true"，否则 Chrome/Firefox/Safari 都按 false 处理。
常见漏点：
- 父级
div[contenteditable="true"]设了spellcheck="true"，但内部p、span等子元素不会自动继承，得单独加 - 某些编辑器框架（如 Slate、Draft.js）会动态生成子节点，新插入的段落若没补上
spellcheck="true"，就静默失效 - Safari（尤其 macOS）对
contenteditable的 spellcheck 支持最弱，即使属性存在，也可能完全不画波浪线
textarea 比 contenteditable 更适合做代码编辑区
想让用户输入 JSON、HTML 片段或变量名时避免误标红？别用 contenteditable，直接上 textarea + 四件套：
-
spellcheck="false"—— 告诉浏览器跳过拼写逻辑 -
autocorrect="off"—— iOS Safari 必加，否则软键盘仍自动更正 -
autocapitalize="none"—— 防止const foo = ()被改成Const foo = () -
inputmode="verbatim"—— 明确提示系统键盘用纯文本模式，绕过数字/符号键盘的校验干扰
这组合在 Google 翻译页、VS Code Web 版、CodePen 编辑器里都验证过，contenteditable 在同一场景下反而容易因嵌套结构漏控、继承混乱或 Safari 行为不一致而失效。
spellcheck="false" 在富文本里不是全局开关
富文本编辑器常混合可编辑与只读内容（比如内嵌代码块、引用块、图片 caption），spellcheck="false" 只对当前元素生效，且只影响可编辑部分：
-
div[contenteditable="true"][spellcheck="false"]下的p若没设spellcheck，会继承父级false；但若p里嵌了个span[contenteditable="false"]，加了也白加——只读元素不响应该属性 - 用户粘贴带格式文本时，新插入的
span或strong默认无spellcheck，也不会继承，需 JS 动态补上（比如监听input或DOMSubtreeModified） - 移动端尤其要注意：iOS Safari 中，
autocorrect="off"优先级高于spellcheck，若漏写，spellcheck="false"就形同虚设
spellcheck 属性无法替代服务端校验
它只控制红色波浪线是否出现，不拦截提交、不修正文本、不触发事件。哪怕看到红线，用户照样能提交 recieve 这种错词。
真实开发中必须区分清楚：
- 前端 UI 提示：靠
spellcheck控制波浪线，仅限可编辑元素，且行为不可控（比如 Firefox 用户需手动开启词典） - 业务校验：用户名、邮箱、密码强度等必须走 JS 正则或 API 校验，不能指望浏览器拼写检查
- 专业术语误报：IP 地址、API key、base64 字符串，加
spellcheck="false"是最轻量解法，比用 CSS 试图隐藏波浪线（text-decoration: none无效）或 JS 拦截输入更可靠
富文本编辑器里最易被忽略的是：spellcheck 是“提示”，不是“能力”——它依赖浏览器内置词典和输入法状态，连 textarea 在 macOS 系统设置关掉「网页文本框中检查拼写」后也会彻底失效，这点没法用代码绕过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
