必须用 DOM 弹窗替代原生 alert/confirm/prompt，所有文案通过 i18n 键值查表、支持插值与动态更新，语言切换时主动刷新已打开弹窗内容。
浏览器原生 alert() 无法多语言，必须自己实现
浏览器的 alert()、confirm()、prompt() 提示框语言完全由操作系统或浏览器 UI 设置决定，document.documentElement.lang 对它**毫无影响**。你改了 lang="zh-Hans"，英文系统里弹出的还是 “Please fill out this field”，不是“请填写此字段”。
常见错误是以为加个 lang 或切个语言包就能让 alert() 变中文——它压根不读你的 HTML 或 JS。
- 原生对话框文案不可控，也不支持插值、HTML 结构、aria 属性
- 移动端 Safari 和部分 WebView 甚至会忽略
navigator.language，直接用系统语言 - 想统一控制提示语，唯一办法是禁用原生，自己封装一个 DOM 弹窗
用 DOM 弹窗替代 alert()，并绑定当前语言包
自己写的弹窗（比如 ）才能真正走你的 i18n 流程：查键、插值、更新 textContent 或 aria-label，还能加按钮文案、图标、动效。
关键点不是“怎么弹”，而是“怎么确保它用对语言”：
- 弹窗初始化时，从当前激活的语言包里取文案，例如
i18n[lang].common_error - 不要在弹窗组件里硬编码字符串，所有文案必须通过
t('key')函数查表 - 如果弹窗支持插值（如“剩余 {count} 次”），语言包里对应值得是模板字符串：
"left_{count}_times": "还剩 {count} 次"，JS 渲染时替换 - 避免把
alert()简单替换成document.createElement('div')后就完事——没挂载到 i18n 更新链里，切换语言后它不会自动刷新
切换语言时，动态弹窗内容也要同步更新
用户点“切换为日语”后，页面上已打开的 Toast、Confirm 弹窗里的文字**不会自动变**。它们是独立 DOM 节点，没监听语言变更事件。
实操建议：
- 给每个弹窗 DOM 节点加一个唯一
data-i18n-key，比如data-i18n-key="confirm_delete" - 语言切换完成后，主动调用一次翻译函数，遍历所有带该属性的节点并更新文本
- 如果弹窗是用函数式 API 调用的（如
showToast({ key: 'network_error' })），内部应缓存 key，并在语言变更时重渲染 - 别依赖 MutationObserver 自动监听弹窗插入——它只管新增，不管已有弹窗的状态同步
error 提示类弹窗要避开 validationMessage
表单校验失败时触发的 invalid 事件，其 event.target.validationMessage 返回的是浏览器原生文案，语言不可控。直接把它塞进你的弹窗，等于又回到了原点。
正确做法是绕过这个值：
- 用
event.target.name或event.target.id当 key 查语言包，比如name="email"→ 查i18n[lang].email.required - 语言包结构建议分层：
{"email": {"required": "邮箱不能为空", "invalid": "邮箱格式不正确"}} - 确保每个表单字段都有明确的
name，否则 fallback 到通用提示（如i18n[lang].form.field_required） - 别忘了
setCustomValidity('')后调reportValidity()，否则用户看不到新提示
最容易被忽略的是：弹窗关闭后再次打开，是否仍用最新语言？很多实现只在首次创建时读一次语言包，之后就固化了。真正的多语言支持，要求每次调用都实时查表，或者监听语言变更广播并刷新所有活跃弹窗实例。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
