探究多语种输入框下spellcheck表单属性的浏览器资源开销

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 —— 这些才是该盯住的地方。