spellcheck属性仅提示浏览器对可编辑元素中疑似拼写错误的单词加红色波浪线，不修正文本、不校验语义、不阻止提交；仅对textarea、input[type="text"/"search"]及contenteditable="true"元素生效，且需系统拼写开关开启、输入法处于英文模式、无autocorrect等属性压制。
直接加 spellcheck="true" 不一定出红线，多数时候是环境没配齐，不是代码写错了。
textarea 里 spellcheck="true" 没反应？先看这三点
这是最常被当成“bug”的场景，其实 textarea 是拼写检查最稳定的载体，但失效往往卡在外部条件：
- 系统级拼写开关没开：macOS 要进「系统设置 → 键盘 → 文本输入 → 在网页文本框中检查拼写」；Windows/Chrome 需在
chrome://settings/languages中启用并安装对应语言词典 - 输入法处于中文模式：哪怕你打的是英文单词，搜狗、微软拼音等输入法会拦截拼写反馈；切换到纯英文直输（比如按 Shift 切换）再试
- 浏览器策略限制：企业部署的 Chrome/Edge 可能通过组策略禁用拼写服务；可临时用个人账号打开隐身窗口验证
示例：<textarea spellcheck="true">Ths is a mistak.</textarea> —— 输入后松开空格或回车，才可能触发波浪线；不是实时逐字标红。
contenteditable 元素 spellcheck 失效？默认是关闭的
contenteditable="true" 的 div 或 p 默认不启用拼写检查，必须显式加 spellcheck="true"，且不继承：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 错写：
<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 元素哪些 type 真正听 spellcheck？别白费劲
不是所有 input 都响应 spellcheck，浏览器优先走格式校验逻辑：
- 可靠生效：
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形同虚设
spellcheck="false" 还是标红线？iOS 是重灾区
在 iOS Safari 上，单靠 spellcheck="false" 基本无效，真正画红线的是系统级 autocorrect：
- 必须组合设置：
spellcheck="false"+autocorrect="off"+autocapitalize="none"+inputmode="verbatim" - 否则用户一输英文，键盘自己弹建议、自动首字母大写、甚至把
const当错词标红 - Android Chrome 相对听话，但也要防备输入法自带提示；混合应用（如 Capacitor）中，WebView 配置可能覆盖 HTML 属性
- 禁用的真实理由不是“防用户输错”，而是避免误标：IP 地址、API key、base64、代码变量名这类内容，浏览器词典根本覆盖不到
复杂点在于：拼写检查本身不触发任何事件、不阻止提交、也不修正文字——它只是个 UI 提示开关，而这个开关的生效链条，横跨 HTML 属性、浏览器策略、系统输入法、甚至键盘固件。真要稳定控制，得从这四层一起下手，缺一不可。
