直接import语言包会破坏SSR可用性，因其在构建阶段静态解析，导致所有语言包全量打入bundle，体积暴涨且服务端无法按请求动态加载；应改用动态import实现运行时按需加载，并配合服务端语言探测与客户端hydration对齐。
为什么直接 import 语言包会破坏 SSR 可用性
服务端渲染时，import 语句在构建阶段就被静态解析，导致所有语言包（如 zh-CN.json、en-US.json）全量打入 bundle，不仅体积暴涨，还让服务端无法按请求语言动态加载。真正需要的是运行时按需加载 + 类型安全的注入方式。
- 避免
import * as locales from './locales'—— 这会让 Webpack 把整个目录打包进主 chunk - 改用
import('path/to/locale').then(...)动态导入，Webpack 会自动切分成独立 chunk - SSR 环境下需配合
globalThis.__locale__或请求头Accept-Language提前确定语言，再调用动态 import - 注意 Node.js 版本：ESM 动态
import()在 v12.20+ / v14.14+ 才稳定支持，低版本需 fallback 到require()+__dirname
如何用依赖注入容器管理 i18n 实例
硬编码 i18n.t() 调用耦合了实现细节，测试和多语言切换都困难。应把 i18n 实例作为可替换依赖注入，而非全局单例。
- 定义接口：例如
interface I18nService { t(key: string, opts?: any): string }，不暴露底层库（如 i18next 或 vue-i18n）细节 - 注入时机：组件初始化时通过构造函数或
setup()接收实例，而非从import { i18n } from '@/i18n'获取 - Vue 场景下，用
provide/inject传递实例比useI18n()更可控——后者隐式依赖顶层 app 实例，不利于嵌套微前端 - React 场景下，用
useContext包裹I18nService，Provider 在根组件或路由级包裹，避免重渲染穿透
动态加载失败时的 fallback 处理策略
网络中断、CDN 故障或 locale 文件路径错误都会导致 import() reject，此时若无降级逻辑，页面可能空白或 key 直出（如 t('login.button') → login.button）。
- 必须设置默认语言包同步加载：主 bundle 中内置
en-US的精简版 JSON，确保首屏可用 - 动态加载失败后，不要静默吞错，应调用
i18n.changeLanguage('en-US')并记录错误到监控系统（如console.error('Failed to load locale:', lang, err)） - 避免在
catch里递归重试——用户刷新页面前，重复请求无意义；建议加指数退避 + 最大重试次数（如 2 次） - SSR 渲染时若动态加载失败，需提前在服务端抛出 error 并返回 500，而不是让客户端降级——否则 SEO 内容丢失
HTML lang 属性与 DOM 更新不同步的坑
<html lang="zh-CN"> 不只是语义标签，它影响屏幕阅读器发音、字体回退、甚至 CSS 的 :lang() 伪类。但很多方案只改内部状态，忘了同步更新 DOM。
立即学习“前端免费学习笔记（深入）”；
- 手动设置：
document.documentElement.lang = 'ja-JP'，必须在语言切换后立即执行，不能依赖后续 re-render - Vue 中避免在
mounted()里写这个逻辑——服务端首次渲染时document不存在，需判断typeof document !== 'undefined' - React 中推荐在自定义 Hook（如
useI18nEffect）里做，且加 cleanup 防止卸载后修改已销毁节点 - 注意浏览器兼容性：
lang值必须符合 BCP 47 标准（如zh-Hans合法，zh_CN不合法），否则部分辅助技术忽略该属性
实际项目中最容易被跳过的，是 SSR 侧语言探测与客户端 hydration 之间的语言状态对齐——服务端用 Accept-Language 解析出 zh-TW，但客户端 localStorage 存的是 zh-HK，若不显式 reconcile，首屏渲染和后续交互就会出现语言撕裂。
