HTML国际化需服务端注入语言包根路径并同步蓝绿环境信号，避免硬编码；语言切换须重建Intl实例，首次以服务端lang为准，仅主动切换时写localStorage并调用/api/locale。
HTML国际化本身不“部署”，它只是前端资源层的文本映射逻辑；真正需要工程化管控的是语言包加载路径、环境标识注入方式，以及切换行为与后端蓝绿/灰度策略的对齐。硬编码语言包 URL 或靠 JS 切换 API 域名，都会导致构建产物绑定环境、无法复用、且破坏网关统一控制。
language.json 路径怎么配置才支持多环境
语言包不能写死为 ./locales/en.json 这类相对路径——构建后静态资源可能托管在 CDN，而开发、测试、预发、生产环境的 base URL 不同。必须由服务端注入根路径：
- Node.js 模板（如 EJS）中：用
<script>window.I18N_BASE = "<%= config.i18nBase %>"</script>注入 - Nginx 反向代理时：通过
sub_filter替换占位符%%I18N_BASE%% - 避免用
process.env.NODE_ENV在构建时拼接——这会让同一份构建产物在 blue/green 环境里加载错的语言包 - 最终加载地址应为类似
${I18N_BASE}/en.json，且 HTTP 响应头需带Cache-Control: immutable（语言包极少变更）
如何让 language switch 和蓝绿部署状态同步
用户手动切语言 ≠ 切换部署环境，但 QA 验证或灰度发布时，二者常需联动。前端不能主动决定流量走向，但可响应服务端透传的环境信号：
- 后端在 HTML 响应头中透传
X-Env: green和X-Locale: zh-Hans，JS 读取后优先采用X-Locale，而非 localStorage 或 navigator.language - 若用户主动点击语言按钮，除更新文案外，应发一个轻量请求到
/api/locale?lang=ja，通知后端记录偏好，并用于后续接口返回本地化错误码 - 不要在
changeLanguage('ja')里同时改 API 域名——这绕过网关，导致鉴权、限流、链路追踪失效 - 蓝绿环境共用同一套语言包，但不同环境可返回略有差异的翻译（如 green 环境的按钮文案加
[BETA]后缀），靠服务端模板差异化渲染
localStorage 存语言偏好时容易踩的坑
存 localStorage.setItem('i18n-lang', 'ja') 看似简单，但实际会引发三类问题：
立即学习“前端免费学习笔记（深入）”；
- 新设备首次访问时，localStorage 为空，但服务端已根据
Accept-Language返回了 zh 页面——此时 JS 读到空值，fallback 到 navigator.language，而安卓 WebView 可能返回""，最终显示英文，与服务端 SSR 不一致 - 用户清缓存后，
localStorage消失，但 cookie 或服务端 session 里还存着上次选的语言，前后端语言错位 - 蓝绿切换期间，用户在 green 环境选了 en，切回 blue 后仍读到 en，但 blue 环境尚未上线该语言支持，导致部分文案 fallback 失败留空
- 正确做法：首次加载时以服务端注入的
document.documentElement.lang为准；仅当用户主动切换时，才写入 localStorage 并同步调用/api/locale
最易被忽略的点是：语言切换后，Intl.DateTimeFormat 和 Intl.NumberFormat 实例不会自动更新。你得重建它们——不是改 document.documentElement.lang 就完事。否则时间格式还是旧 locale 的，比如 “7/7/2026” 和 “2026/7/7” 混用，业务逻辑可能出错。
