spellcheck属性仅控制浏览器对可编辑元素（如text/search类input、textarea、contenteditable元素）的红色波浪线提示，不修正文本、不阻止提交、不校验语义；其生效受浏览器实现、系统词典、输入法及autocorrect等属性共同影响，非强校验手段。
spellcheck 属性是原生支持拼写检查开关的最轻量方式，但它的行为受浏览器、输入类型和用户系统设置共同影响，不能当作强校验手段。
哪些元素能用 spellcheck？
只有可编辑内容的元素才响应该属性，包括：input（仅当 type 为 text、search、url、tel、email、password 以外的类型）、textarea 和设置了 contenteditable 的任意元素。
以下写法无效：
-
<input type="number" spellcheck="true">—— 浏览器忽略 -
<input type="hidden">或<button>上加spellcheck—— 无意义
spellcheck 的取值和实际效果
它接受布尔字符串 "true"、"false"，或不设值（此时继承父级或默认行为）。注意：spellcheck="false" 并非绝对禁用——部分浏览器（如 Chrome 在 macOS 上）仍可能调用系统级拼写检查，尤其当用户开启了全局“自动拼写更正”。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
常见配置建议：
- 禁用拼写提示（如密码、代码片段、ID 输入）：
<input type="text" spellcheck="false"> - 启用（默认即开启，显式写更明确）：
<textarea spellcheck="true"> - 动态控制：用 JS 修改
element.spellcheck = false，但需注意某些浏览器不会立即重绘下划线
为什么有时加了 spellcheck="false" 还有红线？
这不是 spellcheck 失效，而是其他机制在起作用：
- Chrome 在 macOS 上会绕过
spellcheck，直接使用系统“编辑 > 拼写和语法”设置 - Safari 对
contenteditable元素的spellcheck支持较弱，可能始终启用 - 某些输入法（如搜狗、微软拼音）自带纠错，与 HTML 层无关
- 用户浏览器扩展（如 Grammarly）会自行注入检查逻辑，
spellcheck完全无法干预
若必须彻底隐藏拼写下划线，可配合 CSS：input:not([spellcheck="true"]) { text-decoration: none; } 不可靠；更稳妥的是用 *::spelling-error { background: transparent; }（仅 Safari 支持），或接受它存在——毕竟它不影响功能。
真正要记住的不是怎么“关掉”，而是：这个属性只提供提示性开关，不是安全边界，也不替代后端校验。用户是否看到红线，最终取决于他本地开了什么、装了什么、用的什么系统。
