textarea 设置 spellcheck="false" 仍出现红线，主因是 iOS Safari 中 autocorrect="off" 压制拼写建议，或 macOS 系统级拼写检查未关闭；代码编辑器需四件套：spellcheck="false"、autocorrect="off"、autocapitalize="none"、inputmode="verbatim"。
textarea 设置 spellcheck="false" 为什么还有红线
根本不是 spellcheck 属性写错了，而是它被其他属性或系统行为覆盖了。最常见的是 iOS Safari 中 autocorrect="off" 会直接压制拼写建议，此时 spellcheck="false" 形同虚设；macOS 系统级设置（如「键盘 → 文本输入 → 在网页文本框中检查拼写」未勾选）也会让所有 spellcheck 失效。
验证是否真生效，不能只看 HTML 代码，得在浏览器里输一个明显错词（比如 recieve），观察：是否有红色波浪线；右键点击是否出现“更正为…”菜单项。若两者皆无，才算真正禁用成功。
代码编辑器场景必须组合禁用
纯 spellcheck="false" 对代码编辑器（如 <textarea> 写 JSON/YAML/HTML 片段）远远不够——变量名、函数名、路径（如 src/utils/helper.js）会被当成错词反复标红。
可靠方案是四件套齐上：
立即学习“前端免费学习笔记（深入）”；
-
spellcheck="false"—— 告诉浏览器别启动拼写逻辑 -
autocorrect="off"—— iOS 必加，否则软键盘仍自动修正 -
autocapitalize="none"—— 防止首字母意外大写（尤其影响const foo = ...这类结构） -
inputmode="verbatim"—— 明确提示键盘用纯文本模式，避免数字/符号键盘误触发校验
Google 翻译页面的 <textarea> 就是这么写的，兼容性经过大规模验证。
哪些 input 类型根本不响应 spellcheck
spellcheck 对 <input type="email">、<input type="url">、<input type="tel"> 基本无效——浏览器优先做格式校验，拼写检查被跳过；<input type="password">、<input type="number">、<input type="date"> 则完全无视该属性，DOM 解析时就被静默丢弃。
所以代码编辑器场景，别用 input，老实用 <textarea spellcheck="false" autocorrect="off" autocapitalize="none" inputmode="verbatim">。这是目前最稳定、最可控的载体。
contenteditable 区域慎用 spellcheck
富文本编辑器若基于 div[contenteditable="true"] 实现，spellcheck 行为极不可靠：Safari（尤其 macOS）常忽略设置；父元素设了 spellcheck="false"，子节点（如 <p> 或 <span>）会继承，但开发者往往漏查；子元素也不会自动继承，必须显式重复声明。
如果目标是写代码或结构化文本，直接放弃 contenteditable 的拼写控制，改用 <textarea> + 自定义高亮（如 CodeMirror 或 Monaco）更省心。毕竟 spellcheck 本就不是为语法设计的，它只认拉丁词典里的“单词”，对 useState() 或 __proto__ 这类标识符毫无意义。
