spellcheck属性仅提示浏览器可对可编辑元素标红，不保证生效；需系统拼写开关开启、输入法为英文模式、浏览器策略允许，且仅textarea、input[type="text"/"search"]及contenteditable元素支持。
spellcheck 属性不是开关，只是告诉浏览器“可以在这里画红线”，但画不画、画在哪、画成什么样，全看系统、输入法、浏览器策略和元素类型是否匹配。直接加 spellcheck="true" 却没波浪线？大概率不是代码错了，而是环境没对上。
textarea 里 spellcheck="true" 没反应？先查这三件事
这是最常被当成 bug 的场景，其实 textarea 是拼写检查最稳定的载体，失效基本卡在外部条件：
- 系统级拼写开关没开：macOS 要进「系统设置 → 键盘 → 文本输入 → 在网页文本框中检查拼写」；Windows/Chrome 需在
chrome://settings/languages中启用并安装对应语言词典 - 输入法处于中文模式：哪怕你打的是英文单词，搜狗、微软拼音等会拦截拼写反馈；切换到纯英文直输（比如按 Shift 切换）再试
- 浏览器策略限制：企业部署的 Chrome/Edge 可能通过组策略禁用拼写服务；可临时用个人账号打开隐身窗口验证
注意：textarea 中的波浪线不是实时逐字标红，要等你松开空格或回车才可能触发。右键点击错词，若出现“更正为…”菜单，才是真生效。
contenteditable 元素必须显式设 spellcheck
contenteditable="true" 的 div 或 p 默认不启用拼写检查，且不继承父级设置：
- 错写：
<div contenteditable="true"><p>hello</p></div>——p里不会标红 - 正确：
<div contenteditable="true" spellcheck="true"><p spellcheck="true">hello</p></div> - 父级设了
spellcheck="false"会覆盖子级，嵌套结构里容易漏查 - CSS 干扰：如果加了
user-select: none或pointer-events: none，编辑态异常，波浪线可能压根不渲染
哪些 input 类型真正响应 spellcheck？
不是所有 input 都听这个属性，浏览器优先走格式校验逻辑：
- 可靠生效：
type="text"、type="search"—— 显式写spellcheck="true"最稳妥 - 基本无效：
type="email"、type="url"、type="tel"—— 即使加了属性，Chrome/Firefox 通常跳过拼写检查 - 完全无视：
type="password"、type="number"、type="date"—— DOM 解析时就被浏览器静默丢弃 - 移动端特别注意：
inputmode="numeric"或inputmode="tel"会让系统键盘直接禁用拼写逻辑，spellcheck形同虚设
iOS Safari 上 spellcheck="false" 为什么还标红线？
在 iOS Safari 上，单靠 spellcheck="false" 基本无效。真正画红线的是系统级 autocorrect，不是拼写检查：
- 必须组合设置：
spellcheck="false"+autocorrect="off"+autocapitalize="none"+inputmode="verbatim" - 单独写
spellcheck="false"在 iOS 上等于没写 - 验证是否真禁用：输一个明显错词（如
recieve），既无红色波浪线，右键也无“更正为…”菜单才算生效 - 中文内容别指望
spellcheck起作用——所有主流浏览器都不支持原生中文拼写检查
真正复杂的地方不在属性怎么写，而在你得同时跟操作系统、输入法、浏览器策略、DOM 结构四层机制打交道。少一个环节，红线就还在那儿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
