spellcheck属性仅对textarea、text/search类input等可编辑元素生效，且依赖系统拼写设置、英文输入法状态及触发时机；移动端需配合autocorrect等四属性才可靠禁用。
spellcheck 属性不是万能拼写开关，它只在特定元素、特定系统配置、特定输入法状态下才显示波浪线；绝大多数“没反应”问题，根源不在 HTML 代码，而在操作系统或输入法层面。
哪些元素加 spellcheck 才真起作用
只有可编辑且浏览器明确支持的元素才会响应 spellcheck 属性：
-
textarea—— 最稳定，Chrome/Firefox/Safari/Edge 全部认，推荐作为拼写控制主战场 -
input[type="text"]和input[type="search"]—— 可靠生效，但移动端兼容性弱于textarea -
input[type="email"]、input[type="url"]、input[type="tel"]—— 浏览器优先执行格式校验（RFC 规则），常静默忽略spellcheck设置 -
input[type="password"]、input[type="number"]、input[type="date"]—— 完全不响应，DOM 解析时即被丢弃 -
div[contenteditable="true"]及其子节点（如p、span）—— 必须显式为每个可编辑子节点设spellcheck="true"，父级设置不自动继承 -
p、span、div（无contenteditable）—— 即使写了spellcheck="true"，浏览器也静默忽略
spellcheck="true" 为什么没红线？先查这五点
写了 spellcheck="true" 却没波浪线，90% 是环境链断裂，而非代码错误：
- 操作系统拼写检查未开启：macOS 需勾选「系统设置 → 键盘 → 文本 → 在网页文本框中检查拼写」；Windows/Chrome 需在
chrome://settings/languages中启用 English (US) 词典 - 输入法处于中文模式：搜狗、微软拼音等中文 IME 下打英文，Chrome/Edge 直接跳过拼写逻辑；必须按
Shift或Ctrl+Space切出纯英文直输状态 - 没触发校验时机：浏览器不是实时标红，需在输入错词后按
Space、Enter或Tab才触发检查 -
lang属性无效：写lang="en"或lang="zh"不会切换词典，浏览器根本不读取该属性做语言路由 - 移动端 Safari 基本无视：iOS 上
spellcheck="true"几乎无感，波浪线由软键盘控制，HTML 层面无法干预
哪些场景必须关 spellcheck="false"
关闭目的不是“防错字”，而是防止系统词典误标干扰专业内容：
立即学习“前端免费学习笔记（深入）”；
- 代码片段：
const foo = () => {}中const在部分浏览器下被标红，实际是合法关键字 - API key / token：
sk_live_abc123被拆成sk、live等单词误判为拼写错误 - IP 地址、路径、URL、base64 字符串 —— 系统词典完全覆盖不到，标红纯属干扰
- 用户名、医学/法律术语、专有名词 —— 通用词典缺失，误标率高
- 富文本编辑器中的
pre或code块 —— 这些标签默认不可编辑，加spellcheck="false"无效，应作用于其父级contenteditable容器或真实输入层
移动端禁用拼写检查必须用“四件套”
单独写 spellcheck="false" 在 iOS Safari 上大概率失效，软键盘仍会自动修正或弹建议栏：
-
autocorrect="off"—— iOS 最优先的开关，不加就白写 -
autocapitalize="none"—— 防止首字母大写干扰代码或配置（如把const变成Const） -
inputmode="verbatim"—— 明确告诉键盘：别联想、别纠错、别弹词库 -
spellcheck="false"—— 补全语义，覆盖部分 Android 行为
正确写法：<textarea spellcheck="false" autocorrect="off" autocapitalize="none" inputmode="verbatim"></textarea>。Google 翻译页输入框正是如此实现，经大规模验证。
