spellcheck="false"仅对textarea、input[type="text"/"search"]及contenteditable="true"元素生效；其他元素如input[type="email"]等被浏览器静默丢弃，不可编辑标签（p、span等）完全无效。
spellcheck="false" 在哪些元素上真正起作用
只对三类可编辑元素生效：textarea、input[type="text"] 或 input[type="search"]、以及显式设了 contenteditable="true" 的元素（如 <div contenteditable="true">）。其他情况全是无效的：
<ul>
<li>
<code><input type="email">、<input type="url">、<input type="number"> 等，浏览器解析时静默丢弃 spellcheck 属性
<p spellcheck="false"></p>、<span spellcheck="false"></span> —— 不可编辑，属性被忽略<pre class="brush:php;toolbar:false;"></pre> 或 <code> 标签加该属性，毫无意义
为什么写了 spellcheck="false" 还有红线
这不是代码写错了，而是其他机制在底层覆盖了拼写提示逻辑。常见真实原因包括：
- iOS Safari 中，
autocorrect="off"会直接压制拼写建议，此时spellcheck="false"形同虚设 - macOS 系统设置里勾选了「键盘 → 文本输入 → 在网页文本框中检查拼写」，Chrome 会绕过 HTML 属性强制加线
-
inputmode="numeric"或inputmode="tel"让系统键盘跳过拼写逻辑，spellcheck失去作用对象 - 富文本编辑器用
contenteditable实现时，父容器设了spellcheck="false"，但新插入的子节点（如粘贴进来的<p></p>或<span></span>）默认无该属性，也不会继承
textarea 和 contenteditable 的关闭策略差异
textarea 是最稳定的选择，所有主流浏览器都认 spellcheck="false"，且能立即移除波浪线和右键拼写菜单；而 contenteditable 场景复杂得多：
- 必须在根容器（如
<div contenteditable="true">）上同时写 <code>spellcheck="false" - 子节点（如动态插入的
<p></p>、<strong></strong>）需 JS 动态补上spellcheck="false"，监听input或DOMSubtreeModified - Safari 对
contenteditable的spellcheck支持最弱，即使属性存在也可能完全不画波浪线 - Monaco / CodeMirror 等编辑器的“可见区域”往往不是可编辑元素，真正要设属性的是背后那个隐藏的
textarea（如 Monaco 中 class="monaco-editor-background" 下的textarea） -
spellcheck="false"：告诉浏览器不要启用原生拼写高亮 -
autocorrect="off"：iOS Safari 必加，否则照样标红+弹“更正为…”菜单 -
autocapitalize="none"：防const被改成Const，尤其在代码/JSON 场景下明显 -
inputmode="verbatim"：明确提示系统键盘用纯文本模式，绕过数字/符号键盘的校验干扰
移动端必须搭配的四个关键属性
单靠 spellcheck="false" 在 iOS/macOS Safari 上无法彻底禁用红线，必须组合使用：
这四件套缺一不可，漏掉 autocorrect="off" 就等于没关——这是最容易被忽略的硬性依赖。
