spellcheck属性仅对可编辑元素生效：①input[type="text"/"search"/"url"/"tel"/"email"]；②textarea；③contenteditable="true"的元素（如div、p），不可编辑元素（如普通div、p、span）即使设置也无效。
spellcheck 属性在哪些 HTML 元素上真正生效
只有可编辑的元素才会触发浏览器的拼写检查，spellcheck 属性本身不会让不可编辑内容变可编辑。它只对 contenteditable="true" 的元素、input（仅限 type="text"、"search"、"url"、"tel"、"email"）和 textarea 产生实际效果。
常见误区是给 div 或 p 加 spellcheck="true" 却不设 contenteditable，此时浏览器完全忽略该属性。
-
<input type="number">和<input type="hidden">忽略spellcheck -
<textarea spellcheck="false">可以关闭默认启用的拼写检查 - Chrome 和 Safari 对
contenteditable元素的拼写检查支持更稳定；Firefox 在某些版本中对input的支持较弱
如何正确启用并验证 spellcheck 行为
启用后，拼写错误的单词通常以下划红线（red wavy underline）标记，但这个样式不可通过 CSS 直接修改——它是浏览器 UA 样式的一部分。验证是否生效，最直接的方式是输入一个明显拼错的英文词（如 recieve），观察是否有下划线出现。
注意：拼写检查依赖系统级词典和浏览器语言设置，不是所有语言都支持。例如中文输入法下打拼音不会触发检查，但用英文键盘输入 helo 会。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 确保浏览器语言设置中启用了对应语言的拼写检查（Chrome：Settings → Languages → Spell check）
- 移动端 Safari 默认禁用
spellcheck，即使写了也不会显示红线 - 在
input中快速输入再删除，有时会延迟触发，不是 bug，是浏览器防抖策略
spellcheck="true" vs spellcheck="false" vs 省略属性的区别
三者行为并不对称：spellcheck="true" 显式启用；spellcheck="false" 显式禁用；而省略该属性时，浏览器按默认策略处理——对 input 和 textarea 通常是 true，对 contenteditable 元素则取决于 UA 实现，Chrome 默认开启，Firefox 有些版本默认关闭。
- 不要依赖“不写就等于关闭”，尤其在需要一致体验的表单中
-
<input spellcheck>（布尔属性简写）等价于spellcheck="true" - 动态修改需用 JS：
el.spellcheck = false，而不是el.setAttribute('spellcheck', 'false')（后者可能不生效）
为什么 spellcheck 在某些场景下完全没反应
最常被忽略的是输入法上下文干扰。比如在中文 IME 激活状态下输入英文，部分浏览器（特别是旧版 Edge 和某些 Android WebView）会跳过拼写检查，因为输入法接管了文本流。另一个典型原因是字段值通过 JS 动态赋值（如 input.value = "wroong"），此时浏览器不会自动触发重检——得手动调用 input.focus() 再 input.blur() 或模拟一次用户输入。
- 服务端渲染后 JS 注入的
input，需确保 DOM 已挂载再设置spellcheck - Shadow DOM 中的
input需在 shadow root 内正确设置，外部样式或属性不会穿透 - 如果页面启用了
autocomplete="off"，部分浏览器会连带抑制拼写检查逻辑
