spellcheck属性仅控制红色波浪线提示，不影响输入或修正；仅对可编辑元素生效：text/search/tel/email/url类input、textarea（最稳定）、contenteditable元素；不可编辑元素如p/span会静默忽略。
spellcheck 属性不是开关，而是提示；它只影响红色波浪线是否出现，不阻止输入、不修正文字、也不校验逻辑。
哪些元素加 spellcheck 才真起作用
只有三类可编辑元素会响应 spellcheck 属性：
-
<input type="text">、<input type="search">、<input type="url">、<input type="tel">、<input type="email">—— 但注意：type="email"和type="url"实际常被浏览器跳过拼写检查，设了spellcheck="true"也大概率没红线 -
<textarea>—— 最稳定，所有主流浏览器都认，推荐优先用于需精确控制的场景 - 设置了
contenteditable="true"的元素（如<div contenteditable="true">）—— 必须同时写spellcheck="true"或spellcheck="false"，否则多数浏览器默认关闭
常见误用：<p spellcheck="true">、<span spellcheck="false"> —— 这些不可编辑，属性被浏览器静默忽略。
spellcheck="false" 为什么还标红
不是属性没生效，而是其他机制在底层覆盖了拼写提示：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 中，
autocorrect="off"会直接禁用拼写建议，此时spellcheck="false"形同虚设 -
inputmode="numeric"或inputmode="tel"会让系统键盘跳过拼写逻辑，spellcheck失去作用对象 - 父级元素设了
spellcheck="false"，子元素会继承 —— 富文本编辑器嵌套结构里容易漏查 - Chrome 某些旧版本在
autocomplete="off"下连带抑制校验行为
要真正禁用干扰，推荐组合设置：spellcheck="false" + autocorrect="off" + autocapitalize="none" + inputmode="verbatim"。
什么时候该关 spellcheck
关闭目的不是“防错字”，而是“防误标”：
- 输入 IP 地址（如
192.168.0.1），浏览器当单词标红 - 填 API key（如
sk_live_abc123），sk、live被词典误判 - 代码片段（如
const foo = () => {}），const在部分浏览器下触发波浪线 - 用户名、base64 字符串、医学/法律术语等，系统词典根本覆盖不到
这种场景下，spellcheck="false" 是最轻量、最直接的干预方式。比用 CSS 隐藏波浪线（text-decoration: none 不起作用）或 JS 拦截更可靠。
移动端 spellcheck 基本不可控
iOS 和 Android 的原生键盘行为差异大，spellcheck 属性本身对它们影响极小：
- iOS Safari：不渲染波浪线，仅依赖软键盘自身纠错；
spellcheck="true"几乎无感，spellcheck="false"单独使用基本无效 - Android Chrome：响应较弱，更依赖系统级“拼写检查”开关（需用户手动开启）
- Cordova / Capacitor 等混合应用中，WebView 可能完全忽略该属性，需额外检查
WebView.setWebContentsDebuggingEnabled等环境配置
如果你需要跨平台一致的拼写反馈，别指望 spellcheck —— 改用 WebAssembly 拼写库（如 tiny-spellchecker）做客户端校验，尤其当涉及多语言、离线或自定义词典时。
