spellcheck属性仅对textarea、contenteditable="true"的元素（如div）真正生效；input元素（含type="text"）基本忽略该属性，移动端几乎无效。

能关，但默认不生效，且只对 contenteditable 元素或部分 textarea 有效；input 类型（包括 type="text"）基本无视 spellcheck 属性。

spellcheck 属性在哪些元素上真正起作用

它不是全局开关，而是受元素类型和浏览器实现双重限制：

• textarea：绝大多数现代浏览器支持，设 spellcheck="false" 可关闭拼写下划线和右键建议
• contenteditable="true" 的任意元素（如 <div contenteditable>）：行为最稳定，关闭后无波浪线、无上下文菜单拼写建议 <li> <code>input：Chrome、Firefox、Safari 均**忽略**该属性——哪怕写了 spellcheck="false"，输入时仍可能显示红色波浪线（尤其在 macOS 或 Windows 拼写检查开启时）
• 移动端（iOS/Android）：系统级键盘行为优先，spellcheck 几乎无效；改用 inputmode="verbatim" 或 autocomplete="off" 更实际

为什么 input type="text" 上 spellcheck=false 不工作

这不是 bug，是 HTML 规范与浏览器实现的共识：表单控件的拼写检查由操作系统输入法或浏览器 UI 层控制，而非 DOM 属性驱动。关键点：


anything-to-html
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
下载
• spellcheck 是为富文本编辑场景设计的，不是表单验证链的一环
• 即使禁用，用户仍可粘贴带错别字的内容，这和校验逻辑无关
• 想“视觉上去除波浪线”？CSS 无法覆盖原生下划线，只能换方案：比如用 contenteditable 模拟输入框 + JS 管理值，但代价是失去原生 input 的所有语义和无障碍支持

替代方案：比 spellcheck 更可控的输入控制手段

如果你的真实目标是“防止用户输错格式”，拼写检查根本不是解法。应转向真正影响数据质量的机制：

• 用 type="email" / type="tel" / type="url" 触发原生格式校验（注意：required 只管空值，不管格式）
• 用 pattern 写正则约束内容（记住：浏览器自动加 ^$，别自己写；中文需显式包含 \u4e00-\u9fa5）
• 对数字类输入，放弃 type="number" 的幻想——它允许 +、-、e，实时拦截必须用 input 事件 + event.data 判断 + event.preventDefault()
• 服务端永远重验：前端任何控制都可被绕过，spellcheck 尤其如此——它连前端安全边界都算不上

真正容易被忽略的是：很多人把“拼写错误”和“格式错误”混为一谈。spellcheck 处理的是语言词典匹配，而表单校验要解决的是业务规则匹配。两者不在同一层，强行拉通只会浪费调试时间。