spellcheck属性仅是提示而非强制开关，只影响红色波浪线显示，不修正文本、不阻止提交、不替代后端校验；仅对textarea、input[type="text"/"search"]及contenteditable元素生效，且受系统设置、输入法和autocorrect等属性共同影响。

spellcheck 属性不是开关，是提示；它只影响浏览器是否对可编辑内容画红色波浪线，不修正文本、不阻止提交、也不替代后端校验。你写了 spellcheck="false" 还有红线，大概率不是代码错了，而是系统、输入法或浏览器策略没配齐。

哪些元素加 spellcheck 才真起作用

只有三类可编辑元素会响应该属性，且行为差异极大：

• <textarea></textarea> —— 最稳定，Chrome/Firefox/Edge/Safari 都认，显式写 spellcheck="true" 或 "false" 基本都能生效
• <input type="text"> 和 <input type="search"> —— Chrome 默认启用（即使不写），Firefox 默认关闭；iOS Safari 基本无视，别指望它可靠
• <div contenteditable="true"> 及其子元素（如 <code><p></p>）—— 必须显式加 spellcheck="true"，且不继承：父级设了 spellcheck="false"，子级仍需单独声明，否则多数浏览器默认禁用
• 以下完全无效：<input type="email">、<input type="url">、<input type="number">、<input type="password">、<p></p>（不可编辑）—— 浏览器解析时静默丢弃属性

spellcheck="false" 为什么还有红线

这不是属性失效，而是其他机制在底层覆盖拼写提示：


Html2md
使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...
下载
• iOS Safari 中，autocorrect="off" 才是真正压制拼写建议的开关，单设 spellcheck="false" 形同虚设
• inputmode="numeric" 或 inputmode="tel" 会让系统键盘直接跳过拼写逻辑，spellcheck 失去作用对象
• macOS 系统级设置「在网页文本框中检查拼写」开启时，Chrome 会绕过 spellcheck 强制标红
• 搜狗、微软拼音等中文输入法下打英文，常被拦截；必须切换为纯英文直输（比如按 Shift）再试
• 企业部署的 Chrome/Edge 可能通过组策略全局禁用拼写服务；可用个人账号开隐身窗口验证

移动端 textarea 拼写检查禁用要加“四件套”

只写 spellcheck="false" 在 iOS Safari 上基本无效，软键盘仍会自动修正或弹建议栏：

• autocorrect="off" —— iOS 最优先的开关
• autocapitalize="none" —— 防止首字母大写干扰代码或配置
• inputmode="verbatim" —— 明确告诉键盘：别联想、别纠错、别弹词库
• spellcheck="false" —— 补全语义，覆盖部分 Android 行为

正确写法：<textarea spellcheck="false" autocorrect="off" autocapitalize="none" inputmode="verbatim"></textarea>

动态控制 spellcheck 的坑点

用 JavaScript 修改时，关键不是“怎么写”，而是“怎么触发重绘”：

• ✅ 正确：el.spellcheck = false（赋布尔值，触发内部状态更新）
• ❌ 错误：el.setAttribute('spellcheck', 'false')（只改 DOM 属性，部分浏览器不响应）
• ⚠️ 修改后波浪线不会立即消失；已聚焦的输入框需先 el.blur()，再设值，最后 el.focus() 才刷新
• 避免在 input 事件中频繁切换，会导致光标跳动或输入卡顿
• 别用 getComputedStyle 判断当前拼写状态——spellcheck 是 HTML 属性，不是 CSS 可计算样式

真正要记住的不是怎么“关掉”，而是：这个属性只提供提示性开关，用户是否看到红线，最终取决于他本地开了什么、装了什么、用的什么系统。