html 不提供拼写检查能力，spellcheck="true" 仅建议浏览器启用该功能，实际效果取决于浏览器实现与系统语言设置；多语言拼写校验需 js 实现，配合 lang 属性精确控制语言上下文，并考虑协作同步问题。
HTML 本身不提供拼写检查能力，所谓“国际化语境下的拼写错误维护”，实际是前端编辑器、浏览器或后端服务在多语言输入场景中叠加的辅助功能，不是 HTML 标准的一部分。直接靠 或 spellcheck="true" 无法自动修正错字，更不能跨语言统一纠错。
为什么 spellcheck="true" 在多语言 HTML 中经常失效
这个布尔属性只是向浏览器“建议”启用拼写检查，但是否生效、用哪套词典、支持哪些语言，完全取决于用户本地浏览器设置和系统语言环境：
- Chrome 只对
contenteditable元素或<textarea></textarea>生效，且仅加载当前系统默认语言的词典（比如 Windows 上装了中文输入法，但系统区域设为美国，Chrome 就只加载英文词典） -
lang属性影响的是语音合成、字体回退和部分 CSS 选择器（如:lang(zh)），不触发拼写检查引擎切换 - Firefox 对
spellcheck支持更弱，Safari 基本忽略该属性 - 如果页面同时混用
lang="en"和lang="zh"的段落，浏览器不会按lang切换词典——它只认当前焦点元素绑定的系统语言
真正可控的多语言拼写校验必须由 JS 实现
浏览器原生能力不可靠，工程上要落地，得自己集成轻量级纠错逻辑或调用外部服务：
- 中文场景：用
jieba+ 混淆集（如“己已巳”）构建规则库，或接入pypinyin做音似纠错；避免依赖大模型，延迟和成本高 - 英文场景：可复用
pyspellchecker或前端typo-js，但注意词典需按语言加载（en_US/en_GB分开） - 混合文本（如中英夹杂）：不能简单分词，得先用正则识别语言区块（
/[\u4e00-\u9fa5]+/g提取中文，/[a-zA-Z]+/g提取英文），再分别送入对应引擎 - 实时性要求高时，把纠错逻辑放在输入防抖后（如 300ms），并缓存已校验过的短语，避免重复计算
HTML 结构必须配合语言粒度控制
哪怕 JS 纠错逻辑再强，如果 HTML 没按语言切分上下文，结果也会错乱：
- 每个需要拼写检查的文本块，显式加上
lang属性：<p lang="zh">我们今天去公园</p>、<p lang="en">We went to the park</p> - 避免在同一个
contenteditable区域里混写多语言——浏览器和 JS 引擎都难以准确判断边界，容易把 “iPhone” 当成中文错字 - 表单输入框若支持多语言，用
inputmode辅助软键盘（inputmode="text"vsinputmode="verbatim"），但别指望它影响拼写检查 - 服务端返回的富文本（如 CMS 输出），务必确保每个
<span></span>或<div> 都带正确 <code>lang，否则前端 JS 扫描时会漏判最易被忽略的一点：拼写纠错不是“修完就完事”，它必须和协作状态同步。比如用户 A 标记“光林”为错字，用户 B 同时输入“光林”，这个标记要不要合并？是否允许忽略？这些交互逻辑一旦脱离 OT/CRDT 同步模型，多人编辑时立刻出现视图不一致——而 HTML 的
lang和spellcheck完全不参与这个过程。
