spellcheck属性本身无资源开销，仅是提示信号；词典仅在用户英文输入、焦点在可编辑元素、系统拼写开关启用等条件满足时才加载并触发检查，此前零CPU、零内存、零网络请求。
spellcheck 属性本身不产生可测量的资源开销，它只是个提示信号，浏览器是否加载词典、是否启动拼写检查逻辑，完全取决于输入行为和系统环境，而非属性存在与否。
spellcheck="true" 不会预加载词典或占用内存
浏览器不会因为写了 spellcheck="true" 就提前加载英文词典、中文模型或任何语言资源。词典只在满足以下全部条件时才可能被拉起：
- 用户正在用英文键盘输入（非中文输入法的“英文模式”）
- 当前焦点落在
textarea或input type="text"上 - 系统级拼写开关已启用（如 macOS 的「在网页文本框中检查拼写」）
- 浏览器进程里该语言词典尚未被卸载（通常只在长时间无拼写操作后释放）
也就是说，spellcheck="true" 在 DOM 里躺着时，0 CPU、0 内存、0 网络请求 —— 它不触发任何后台任务。
真正耗资源的是“实际触发拼写检查”的那一刻
当用户松开空格键、回车或切换焦点，且满足上述环境条件时，浏览器才会做这几件事：
- 从系统词典服务（如 macOS 的 NSLanguageGrammarChecker、Windows 的 SpellCheck API）拉取当前单词的候选建议
- 对连续英文单词做分词（不是正则切分，而是基于 ICU 的 Unicode 分界算法）
- 在渲染层叠加波浪线（
paint阶段额外绘制，非合成层，不影响 FPS）
这个过程单次耗时通常 spellcheck 属性无关，和输入量与词典响应速度强相关。
多语种混排场景下，开 spellcheck 反而更省资源
很多人误以为“中英混合就该关 spellcheck”，其实恰恰相反：
-
spellcheck="false"是静态指令，浏览器直接跳过所有拼写逻辑，不查、不分词、不渲染波浪线 —— 开销为 0 -
spellcheck="true"在中文输入法下（如搜狗拼音处于「中文」状态），Chrome/Edge 会主动跳过拼写检查流程，连词典都不调用 —— 开销仍为 0 - 只有当用户切到英文键盘、输英文单词、且系统词典就绪时，才真正消耗资源
所以，spellcheck="true" 在多语种输入框里，实际是“按需激活”，不是“常驻监听”。你不需要为防性能问题而全局禁用它。
移动端和 WebView 是唯一需要警惕的例外
iOS Safari 和 Android WebView（尤其微信 X5）对 spellcheck 的实现极不统一：
- 它们可能把
spellcheck="true"当作开启系统键盘拼写建议的信号，导致键盘频繁弹出候选栏、触发 autocorrect 重排 —— 这部分开销来自输入法引擎，不是浏览器 - 某些 WebView 会错误地对
input type="tel"也尝试加载词典，造成无意义的初始化延迟 - 验证方式很简单：打开 DevTools → Performance → 录制一次输入，看是否有
SpellCheck相关 task —— 绝大多数情况下，你根本看不到它
真正影响性能的从来不是 spellcheck 属性本身，而是你有没有在 contenteditable 区域里堆了上千个带 spellcheck="true" 的子节点，或者在 React/Vue 中反复 toggle 它导致 layout thrashing —— 这些才是该盯住的地方。
