contenteditable元素需显式设置spellcheck="true"才触发拼写检查，且不继承父级属性；textarea支持最一致但仅限纯文本；iOS Safari禁用拼写需四属性组合；spellcheck仅控制红线显示，不校验也不拦截提交。
contenteditable 元素必须显式写 spellcheck="true"
只加 contenteditable="true" 不会触发拼写检查——Chrome/Firefox/Safari 默认都当它是 spellcheck="false"。哪怕父级 div 已设 spellcheck="true"，子 p 或 span 也不会继承，得每个可编辑块单独加。
常见错误是这样写：<p contenteditable="true">hello world</p>，结果没红线。正确写法是：<p contenteditable="true" spellcheck="true">hello world</p>。
如果用 React/Vue 动态渲染内容，注意 DOM 挂载后才生效；服务端渲染的初始 HTML 必须带该属性，否则 JS 补上可能延迟或无效。
textarea 是最稳的选择，但不适用于富文本
textarea 对 spellcheck 支持最一致：所有浏览器都认 spellcheck="true"，输 recieve 立刻出红线，spellcheck="false" 也基本秒关。但它只能处理纯文本，无法支持加粗、链接、图片等富文本格式。
所以别试图用 textarea 替代 contenteditable 做富文本编辑器——不是属性配不对，是能力边界问题。真要兼顾拼写提示和格式能力，得接受 contenteditable 的不稳定性，或引入第三方库（如 spell-ui）接管 UI 层。
spellcheck="false" 在 iOS Safari 上基本无效
单独写 spellcheck="false" 对 iOS Safari 没用。它根本不画波浪线，也不响应这个属性，而是由系统键盘的 autocorrect 控制是否标红/弹建议。
要真正禁用干扰，必须组合四件套：spellcheck="false" + autocorrect="off" + autocapitalize="none" + inputmode="verbatim"。漏任何一个，比如只关 spellcheck，用户在输入 API key（如 sk_live_abc123）时仍可能看到 sk 被标红。
Android Chrome 略好些，但若系统键盘开启了拼写检查，照样自己标红线——这跟 spellcheck 无关，是原生行为。
拼写检查不是校验，红线不等于错字
spellcheck 只影响红色波浪线显示，不拦截提交、不触发事件、不修正文本。用户完全可以无视红线提交 helo，后端照样收到。
它依赖系统词典和浏览器语言设置：macOS 需打开「系统设置 → 键盘 → 文本输入 → 在网页文本框中检查拼写」；Chrome 需在 chrome://settings/languages 中启用并安装对应语言词典。没这些，写了 spellcheck="true" 也是白搭。
更关键的是，它对专有名词、代码变量（如 useState）、base64、IP 地址完全无感，误报率高。所以关掉不是为了“防错”，而是防误标——这点容易被忽略，却直接决定用户体验是否被干扰。
