spellcheck属性仅是开关信号，不驱动拼写检查引擎启动；真正影响拼写检查的是系统服务、输入法语言、autocorrect设置及焦点状态，而非该属性本身。
spellcheck 属性本身不触发拼写检查引擎启动
拼写检查不是由 spellcheck 属性“驱动”的，它只是个开关信号。浏览器是否真调用拼写引擎、加载词典、扫描文本，取决于：系统级拼写服务是否启用、当前输入法语言、用户是否在英文模式下打字、以及是否有焦点且内容可编辑。属性设为 "false" 时，Chrome/Firefox/Edge 大多跳过词典加载；但 Safari（尤其 macOS/iOS）可能仍预加载轻量词典用于 autocorrect，这不是 spellcheck 的责任，而是 autocorrect 行为的一部分。
资源占用集中在词典加载与实时匹配，而非 spellcheck 属性解析
真正吃内存和 CPU 的环节是：词典文件解压（几十 KB 到几 MB）、对每个单词做哈希查表、动态排除代码标识符（如 useState、fetch()）——这些都发生在浏览器内核层，和你写没写 spellcheck="false" 无关。实测对比：<textarea spellcheck="true"></textarea> 和 <textarea spellcheck="false"></textarea> 在 Chrome DevTools 的 Memory 跟踪中，堆内存差异小于 50 KB，CPU 占用曲线无显著区别。真正高开销的是：长文本 + 英文输入法 + 系统拼写开启 + 没关 autocorrect —— 此时即使 spellcheck="false"，iOS 键盘仍会做本地纠错计算。
- 词典加载只在首次聚焦 textarea 时发生，后续复用缓存
- 拼写检查不联网，所有词典来自操作系统或浏览器内置（如 Chromium 自带 en-US.dic）
- contenteditable 元素比 textarea 更耗资源：需遍历 DOM 树做分词，而 textarea 是纯字符串流
隐私风险几乎为零，但 autocorrect 和 inputmode 会改变行为边界
spellcheck 属性不上传任何数据，也不触发网络请求。所谓“隐私风险”实际来自三个常被混淆的机制：
-
autocorrect="on"（iOS/macOS 默认）：键盘在本地做候选词生成，不外传，但可能记录模糊匹配结果用于优化建议 -
inputmode="text"：唤起全功能英文键盘，含拼写建议栏；换成inputmode="verbatim"后，键盘退化为纯字符输入，无建议、无联想 - 浏览器扩展（如 Grammarly）：它们劫持 input 事件并上传文本，
spellcheck对其完全无效
所以如果你担心隐私，重点不是删 spellcheck，而是关掉 autocorrect、禁用可疑扩展、避免在敏感场景用 inputmode="text"。
textarea 中 spellcheck="false" 仍见红线？那根本不是 spellcheck 在工作
看到红色波浪线，90% 情况下是以下某项在起作用，和 spellcheck 属性无关：
- iOS Safari 忽略
spellcheck，只认autocorrect="off"；红线其实是 autocorrect 的“疑似错误”提示 - macOS 系统设置「在网页文本框中检查拼写」开着，此时
spellcheck="true"才生效，false只是放弃主动触发，但系统服务仍可能介入 - 你用的是 Monaco/CodeMirror 这类编辑器，真正起作用的是隐藏的
textarea（比如 class="monaco-editor-background" 下那个），而不是你看到的渲染层 - 输入法处于中文拼音模式，搜狗/微软拼音会自己标红“错别字”，这和 HTML 层完全隔离
真正要盯住的，从来不是 spellcheck 写没写对，而是 autocorrect、inputmode、系统设置、以及那个看不见的 textarea 是否被正确配置。
