spellcheck="true"仅向浏览器建议启用拼写提示，不暴露校验过程、不提供回调或错词位置，JS无法与其配合，必须禁用原生功能后通过监听input、正则分词、调用外部词典API并手动高亮来替代实现。
spellcheck="true" 和外部词典库根本不在同一层
浏览器原生 spellcheck 属性只是向渲染引擎“建议启用拼写提示”，它不暴露校验过程、不提供回调、不返回错词位置，更不会把文本交给 JS 处理。你给 <input type="text" spellcheck="true"> 加了属性，看到红色波浪线，那完全是浏览器内部调用系统词典的结果，JS 拿不到任何中间数据——没法“配合”，只能“替代”。
想用外部词典库，必须绕过 spellcheck 原生逻辑
真实可行的路径是：禁用原生拼写检查，自己接管输入、分词、查词、高亮全流程。关键动作包括：
- 显式设置
spellcheck="false"，避免浏览器波浪线干扰视觉判断 - 加上
autocorrect="off"（尤其 iOS Safari 必须加，否则软键盘自动修正会覆盖你的校验结果） - 监听
input事件，但别每次敲字都查——加防抖（debounce ≥ 300ms），否则性能崩 - 用正则提取英文词：
/[a-zA-Z]+/g；中文词用/[\u4e00-\u9fa5]+/g（注意中英混排时边界可能断裂） - 英文查本地轻量词典（如
bloom-filters-spellchecker）或 LanguageTool API；中文必须走服务端 API（百度 AI / 腾讯文智 / PaddleNLP），纯前端无法可靠识别“欢迊”这类形近错字 - 高亮不能依赖浏览器波浪线，得手动插入
<mark class="spell-error"></mark>或用 canvas/svg 渲染下划线
input[type="text"] 上直接挂词典校验容易踩的坑
很多开发者以为在 input 上加个事件监听就能搞定，结果发现：
-
input事件里拿到的是整个字段值，但用户可能只改了中间一个字母，全量分词+查词浪费 CPU - 移动端输入法上屏延迟（尤其拼音输入），
input触发时机和实际文本不一致，导致错词漏判 -
inputmode="latin"或inputmode="verbatim"不影响词典行为，只控制键盘类型；真正压制系统拼写的，是autocorrect="off"和系统级设置 - 如果页面有多个
input，且支持动态增删，记得每次插入新节点后手动初始化 spellcheck 和事件绑定，否则新字段不校验
textarea 是更稳妥的起点，但仍有边界限制
比起 input[type="text"]，textarea 更适合做自研拼写校验，因为：
立即学习“前端免费学习笔记（深入）”；
- 它天然支持多行、换行符保留，分词上下文更完整
- 移动端软键盘行为比单行 input 更可预测（尤其 iOS 上
autocorrect="off"对 textarea 生效更稳定） - 你可以用
getSelection()+setSelectionRange()精准定位错词并高亮，input的 selection API 在某些 Android 键盘下会失效 - 但注意：textarea 默认没有字符数限制，长文本下全量校验仍需切片或流式处理，否则卡顿明显
真正难的不是调用哪个词典库，而是如何让校验结果和用户编辑意图对齐——比如光标在错词中间时，是标整个词还是只标当前片段？这个逻辑没标准答案，得根据产品场景定。
