spellcheck属性：浏览器拼写检查的“开关”，但你可能一直用错了
在构建网页表单或富文本编辑器时，你是否遇到过这样的困扰：用户输入的IP地址被标上了刺眼的红色波浪线，或者一串API密钥中的片段被浏览器误认为是拼写错误？这背后，往往就是浏览器的原生拼写检查功能在“热心”地工作。而控制这份“热心”程度的，正是我们今天要聊的 spellcheck 属性。
简单来说，这个属性就是一个指令，它告诉浏览器：对于这个可以编辑的区域，要不要启动原生的拼写检查。请注意，它仅仅是高亮疑似错误的单词，而不会自动进行任何修正。它的作用，更像是一个温和的提示者，而非强硬的纠正者。
哪些元素能用 spellcheck？
虽然 spellcheck 被归类为全局属性，但它的生效是有条件的——只作用于那些可编辑的内容。具体来说，主要包括以下几类：
input元素，当其类型为text、search、url、tel、email等时（注意，password类型通常不适用）。textarea元素。- 任何设置了
contenteditable="true"的HTML元素，比如div或p。
反过来看，对于那些只读的或者根本不可聚焦的元素（比如一个普通的 span，或者没有设置 contenteditable 的 div），即使你强行加上 spellcheck="true"，浏览器也多半会置之不理。
spellcheck="false" 的真实用途：关掉“误报”，而非关掉“功能”
设置 spellcheck="false" 的核心场景，往往不是为了阻止用户发现拼写错误，而是为了避免浏览器产生大量无意义的干扰性提示。想想看，在下面这些情况下，那条红色波浪线除了让人心烦，还有什么用呢？
立即学习“前端免费学习笔记（深入）”；
- 输入技术参数：比如一个IP地址
192.168.0.1，它根本不是一个英文单词，被标红毫无道理。 - 填写密钥或令牌：像
sk_live_abc123...这样的API密钥，其中的sk、live很可能被浏览器的内置词典误判。 - 在编辑器中写代码：在富文本编辑器内嵌的代码块里，
const foo = () => {}这样的语句，const等关键字在某些浏览器下也会触发拼写提示。 - 专业领域表单：涉及大量医学、法律或特定行业术语的输入框，浏览器的通用词典完全无法覆盖。
这时候，给对应的输入框或编辑区域加上 spellcheck="false"，可以说是最轻量、最直接的解决方案。相比用Ja vaScript去拦截事件，或者用CSS费力地隐藏那些下划线，这个方法要可靠和优雅得多。
兼容性与默认行为：那些容易踩坑的细节
从兼容性角度看，spellcheck 属性得到了所有现代浏览器的广泛支持（Chrome 10+、Firefox 2+、Safari 6+、Edge、Opera等）。然而，魔鬼藏在细节里，它的默认行为并不统一，这恰恰是开发中容易出问题的地方：
- 默认开关不一：对于常见的
input[type="text"]和textarea，大多数浏览器默认是开启拼写检查的（即等效于spellcheck="true"）。但需要注意，Safari 在某些历史版本中，对textarea的默认设置是关闭的。 - 属性继承：如果父元素设置了
spellcheck="false"，那么其内部的可编辑子元素会继承这个设置。这个特性容易被忽略，可能导致你试图在局部禁用检查，却因为外层容器的设置而失败。 - 它的本质是“提示”：最后必须强调一点，
spellcheck是一个提示性属性。这意味着浏览器有权选择忽略它。它不会触发任何Ja vaScript事件，你也无法通过脚本去监听“拼写检查状态是否发生了变化”。
所以，请牢记它的定位：它只是一个用户体验层面的微调工具。别指望用它来实现服务端的校验逻辑——该做的输入验证，后端一个都不能少。也别试图用它来控制光标行为或做输入限制。它的全部工作，就是决定画不画那条红色的波浪线。理解这一点，就能把它用在最该用的地方。
