spellcheck属性仅对textarea、input[type="text/search"]及显式设contenteditable="true"的元素生效；email/url/tel/password/number/date等input类型及非可编辑p/pre/code均忽略该属性。
spellcheck 属性在哪些元素上根本不起作用
不是所有带 contenteditable 或文本输入能力的元素都会响应 spellcheck。浏览器在解析时会静默丢弃该属性，你写了也等于没写：
-
<input type="email">、<input type="url">、<input type="tel">：格式校验优先级更高，拼写检查被跳过 -
<input type="password">、<input type="number">、<input type="date">：DOM 解析阶段直接忽略spellcheck属性 -
<p>、<pre>、<code>（未设contenteditable="true"）：不可编辑，无拼写检查入口，加了也白加
真正只认三类： <textarea>、<input type="text"> / <input type="search">、显式声明 contenteditable="true" 的元素（如 <div> 或 <p>）。
为什么 spellcheck="false" 还有红色波浪线
这不是代码失效，而是其他机制在底层覆盖了你的设置：
- iOS Safari 中，
autocorrect="off"才是压制拼写建议的开关，单设spellcheck="false"几乎无效 - macOS 系统级开关「在网页文本框中检查拼写」开启时，Chrome 会绕过
spellcheck强制标红 -
inputmode="numeric"或inputmode="tel"会让系统键盘直接禁用拼写逻辑，spellcheck失去作用对象 - 中文输入法（如搜狗、微软拼音）下打英文，常被输入法拦截；必须按
Shift切纯英文直输模式再试
contenteditable 元素 spellcheck 不生效的典型陷阱
spellcheck 在 contenteditable 上不继承，且默认为 false，这是最常踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 父级
<div contenteditable="true" spellcheck="false">下的<p>仍不会标红——除非你单独给<p spellcheck="true"> - 嵌套结构里，
<div spellcheck="true"><p>hello</p></div>中的p依然不会触发检查 - CSS 若含
user-select: none或pointer-events: none，会导致编辑态异常，波浪线压根不渲染 - Safari（尤其 macOS 13+ 和 iOS 16+）在焦点获取后可能短暂显示下划线（约 200ms），不是 bug，是其异步词典检查机制
排查 spellcheck 是否真生效的实操步骤
别只看代码，要验证真实行为：
- 用英文单词测试，比如输入
recieve后敲空格或回车——不是逐字实时标红，而是在单词结束时触发 - 右键点击该区域，看是否有「更正为…」菜单项；没有，说明拼写检查确实被禁用
- 检查系统设置：macOS 要进「系统设置 → 键盘 → 文本输入 → 在网页文本框中检查拼写」；Windows/Chrome 需在
chrome://settings/languages中启用并安装英文词典 - Electron 应用需确认主进程
webPreferences.spellcheck: false是否开启——若开了，前端所有spellcheck都会被全局屏蔽
spellcheck 本质是调用操作系统级拼写服务，它不支持中文，不处理上下文（比如把 their 写成 there），也不随语言切换动态生效。真要纠错，得另上 JS 方案。
