spellcheck属性仅触发浏览器对可编辑元素中疑似拼写错误的单词加红色波浪线，不修正文本、不校验、不拦截提交；仅对text/search输入框、textarea及contenteditable=true元素生效，移动端需配合autocorrect="off"等属性才可靠禁用。
spellcheck 属性只控制浏览器高亮，不修正也不校验
它只是让支持的浏览器在可编辑区域里对疑似拼写错误的单词加红色波浪线，不改文本、不拦截提交、不触发任何事件。服务端校验和前端逻辑校验必须独立实现，不能依赖它。
常见误解是以为设了 spellcheck="true" 就等于“启用了拼写检查功能”——实际只是开了个 UI 提示开关，且这个提示本身还受系统输入法、浏览器策略、其他 HTML 属性压制。
- 波浪线出现的前提：用户松开键盘（比如输完单词按空格或回车），不是实时逐字检查
- 右键菜单里能看到“拼写建议”选项，才是 spellcheck 真正生效的信号
- 即使看到红线，也可能是 iOS/macOS 的
autocorrect在作祟，跟spellcheck无关
哪些元素加 spellcheck 才真正起作用
只有三类可编辑元素响应该属性：input（仅限 type="text"、"search"）、textarea、以及带 contenteditable="true" 的任意元素（如 div、p）。
其他情况一律无效：
-
input type="email"、"url"、"number"、"password"—— 浏览器根本不对其做拼写分析，设spellcheck="false"也没意义 -
span、label、p（没加contenteditable）—— 属于“不可编辑”，属性被忽略 - 设置了
readonly或disabled的input/textarea—— 失去编辑能力，spellcheck 不触发
spellcheck="false" 为什么经常失效
根本问题不是 spellcheck 写错了，而是移动端系统级输入法（尤其是 iOS Safari）绕过了它。真正的红线来自 autocorrect，不是拼写检查。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
要可靠禁用所有拼写/自动更正干扰，必须组合设置：
-
spellcheck="false"—— 告诉浏览器别启动拼写检查逻辑 -
autocorrect="off"—— iOS 必须项，禁用系统自动更正（否则照样标红+弹建议） -
autocapitalize="none"—— 防止首字母意外大写（常伴随 autocorrect 激活） -
inputmode="verbatim"—— 明确提示键盘用纯文本模式（对代码、token、用户名等场景很关键）
单独写 spellcheck="false" 在 iOS 上基本等于没写。
contenteditable 元素的 spellcheck 行为最不稳定
相比 textarea，contenteditable 容器的拼写检查行为浏览器差异最大：Chrome 默认激进启用，Firefox 较克制，Safari 则容易继承父级或样式影响。
如果你用 div contenteditable="true" 做富文本编辑器，要注意：
- 显式写
spellcheck="false"可能被忽略，需配合上述全套属性 - 子元素带
lang属性（如<p lang="en"></p>）才可能触发对应语言词典，否则默认按页面推断 - 动态插入内容后，已有的波浪线不会自动刷新；需触发重排或模拟一次用户编辑（如 focus + blur）
真正需要稳定拼写控制的场景（比如代码编辑、表单 token 输入），别指望 spellcheck，该上 WebAssembly 拼写库就上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
