JavaScript国际化需自行管理翻译资源并用Intl API格式化，语言包动态加载、标准BCP 47代码、显式切换UI+持久化、locale与翻译一致、避免硬编码格式、安全处理插值与复数。
JavaScript 国际化（i18n）本身不内置多语言支持，Intl API 只负责格式化（日期、数字、货币、排序），不处理翻译文本。要实现真正的多语言切换和本地化，必须自己管理翻译资源 + 用 Intl 做格式化适配。
怎样加载和切换语言包
核心是维护一个语言键值映射对象，并在运行时动态替换。不能依赖浏览器自动识别语言后就“开箱即用”，需要显式加载对应语言的 JSON 文件或模块。
- 推荐用 ES 模块动态导入：
import(`./locales/${lang}.js`)，避免打包时全量引入 - 如果用 JSON，需注意跨域限制：放在同源静态目录下，或由后端返回；直接
fetch('./locales/zh.json')是常见做法 - 语言代码要用标准 BCP 47 格式（如
zh-CN、en-US），别用zh或english这类非标准写法，否则Intl格式化可能降级或出错 - 切换语言后，所有已渲染的文本不会自动更新——必须手动触发重渲染（React/Vue 中响应式更新；原生 JS 需重新赋值
textContent或 innerHTML）
为什么不能只靠 navigator.language
navigator.language 返回的是用户系统/浏览器首选语言，但实际业务中它不可靠：
- 用户可能用英文系统但需要中文界面（比如海外华人）
- 企业内网环境常被策略强制设为英文，但员工需本地语言
- 移动端 WebView 下该值可能固定为宿主 App 语言，与用户设置脱节
- 隐私模式或某些浏览器扩展会屏蔽或伪造该值
正确做法是：以 navigator.language 作默认 fallback，但必须提供显式语言切换 UI（如顶部语言下拉），且将用户选择持久化到 localStorage 或 cookie。
立即学习“Java免费学习笔记（深入）”；
日期/数字/货币格式怎么随语言自动变
这部分才是 Intl 的强项，但要注意 locale 参数必须和语言包一致，否则格式和文案会错位。
- 日期格式：
new Intl.DateTimeFormat('ja-JP').format(new Date())→"2024/06/12"；用'de-DE'就变成"12.06.2024" - 数字分组：
new Intl.NumberFormat('en-US').format(1234567)→"1,234,567"；'zh-CN'是"1,234,567"（注意：中国也用千分位，但小数点是点） - 货币符号位置、分隔符、小数位数都由 locale 决定：
new Intl.NumberFormat('fr-FR', { style: 'currency', currency: 'EUR' }).format(123.45)→"123,45 €" - 切勿硬编码格式逻辑（比如 “把小数点换成逗号”），所有格式化必须走
Intl，否则无法覆盖阿拉伯语等从右向左（RTL）场景
常见坑：翻译键嵌套、复数、占位符怎么处理
纯扁平 key（如 login.title）容易维护，但遇到复数、性别、上下文差异时就会力不从心。
- 简单插值可用模板字符串：
`${t('welcome')}, ${name}`，但要防 XSS —— 若name来自用户输入，必须先做 HTML 转义或用textContent - 复数规则不能靠 if 判断数量，要用
Intl.PluralRules：new Intl.PluralRules('ru-RU').select(count)返回'one'/'few'等，再查对应翻译 - 嵌套结构（如
{ user: { profile: { title: '个人资料' } } }）会让 key 路径变长，建议用函数封装访问：t('user.profile.title')内部按点分割取值，比手写dict.user.profile.title更健壮 - 不要在翻译文本里塞 HTML 标签（如
"点击这里继续"），应拆成带占位符的结构：t('click_here_to_continue', { link: '这里' })，再用安全方式插入
真正难的不是加载几个 JSON，而是让格式化、复数、RTL、字体渲染、日期计算全部对齐同一 locale，且不和业务状态耦合。很多项目卡在“中英文能切，日文时间一显示就乱码”，问题往往出在 locale 字符串传错了，或者用了 en 却期待日本格式。
