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></p>、<pre class="brush:php;toolbar:false;"></pre>、<code>（未设 contenteditable="true"）：不可编辑，无拼写检查入口，加了也白加

真正只认三类： <textarea></textarea>、<input type="text"> / <input type="search">、显式声明 contenteditable="true" 的元素（如 <div> 或 <code><p></p>）。

为什么 spellcheck="false" 还有红色波浪线

这不是代码失效，而是其他机制在底层覆盖了你的设置：

• iOS Safari 中，autocorrect="off" 才是压制拼写建议的开关，单设 spellcheck="false" 几乎无效
• macOS 系统级开关「在网页文本框中检查拼写」开启时，Chrome 会绕过 spellcheck 强制标红
• inputmode="numeric" 或 inputmode="tel" 会让系统键盘直接禁用拼写逻辑，spellcheck 失去作用对象
• 中文输入法（如搜狗、微软拼音）下打英文，常被输入法拦截；必须按 Shift 切纯英文直输模式再试

contenteditable 元素 spellcheck 不生效的典型陷阱

spellcheck 在 contenteditable 上不继承，且默认为 false，这是最常踩的坑：

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

• 父级 <div contenteditable="true" spellcheck="false"> 下的 <code><p></p> 仍不会标红——除非你单独给 <p spellcheck="true"></p>
• 嵌套结构里，<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 方案。