spellcheck属性仅提示浏览器对可编辑元素中疑似拼写错误的英文单词加红色波浪线，不阻止提交、不修正文本、不影响原生校验；仅对textarea、input[type="text"/"search"]及contenteditable="true"元素生效，且受浏览器、系统设置及输入法共同影响。
spellcheck 属性不参与表单输入验证，它既不阻止提交、不修正文本、也不影响 required 或 pattern 等原生校验逻辑。它的唯一作用是向浏览器提示：是否对可编辑内容中疑似拼写错误的英文单词加红色波浪线。
哪些表单元素加 spellcheck 才真有反应
只有三类可编辑元素会响应该属性，且行为差异明显：
-
<textarea></textarea>—— 最稳定，Chrome/Firefox/Edge/Safari 均支持，推荐用于需明确控制的场景 -
<input type="text">和<input type="search">—— 可设，但 Firefox 默认关闭、iOS Safari 基本无视 -
<input type="email">、<input type="url">、<input type="tel">—— 浏览器通常跳过拼写检查，写了也大概率没红线 -
<input type="password">、<input type="number">、<input type="date">—— 属性被静默丢弃，完全无效
spellcheck="false" 不是“关掉拼写”，而是“关掉干扰”
它解决的不是“用户输错字”，而是“系统误标红”这类体验干扰：
- API key（如
sk_live_abc123）中sk、live被当英文单词标红 - IP 地址（如
192.168.0.1）被拆成单词触发提示 - 代码片段（如
const foo = () => {}）中const在部分浏览器下标红 - 用户名、base64 字符串、医学术语等超出系统词典覆盖范围的内容
此时单独设 spellcheck="false" 是最轻量干预；比用 CSS 隐藏波浪线（*::spelling-error 仅 Safari 支持）或 JS 拦截更直接可靠。
根据ui图生成前端页面
下载
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
立即学习“前端免费学习笔记（深入）”；
移动端和富文本里 spellcheck 基本不可控
这是最容易被忽略的现实约束：
- iOS Safari 完全忽略该属性，拼写提示由软键盘自身控制；
spellcheck="true"几乎无感，spellcheck="false"单独使用基本无效 -
contenteditable元素默认不启用拼写检查，子节点（如<p></p>）必须显式写spellcheck="true"，且父级spellcheck="false"会继承覆盖 - React/Vue 中写
spellcheck={false}正确，但注意 JSX 编译后为小写spellcheck，不是spellCheck - autocorrect="off"、inputmode="verbatim"、autocapitalize="none" 这些属性在移动端常比
spellcheck更有效
真正难的不是怎么配 spellcheck，而是接受它只是个提示性开关——是否标红，最终取决于用户本地开了什么输入法、装了什么扩展、甚至系统设置里勾没勾「在网页文本框中检查拼写」。
