HTML国际化需隔离语言包、Intl实例和lang作用域：必须按BCP 47完整码（如zh-HK）加载语言包，每次切换新建Intl.DateTimeFormat/NumberFormat实例，显式设置每个语义标签的lang属性，动态DOM插入后手动调用翻译函数并传入当前语言包与Intl实例。
HTML国际化怎么隔离？
国际化本身不是安全机制，所谓“隔离”不是指防 XSS 或跨域，而是指语言资源、DOM 更新逻辑、格式化实例之间互不干扰。真正在工程中需要隔离的，是不同语言包加载后的状态、Intl 实例、以及 lang 属性作用域。
常见错误现象：切换语言后，日期控件仍用旧 locale 格式；document.documentElement.lang 改了，但 <p lang="en">Hello</p> 里的标点间距没变；多个模块共用一个翻译函数，结果 A 模块切到 zh-HK，B 模块却渲染成 zh-CN 的货币符号。
- 语言包必须按 BCP 47 完整码加载（如
zh-HK、en-US），不能简单 fallback 到zh就完事——zh-HK和zh-CN的千分位分隔符、货币符号、甚至“软件”/“软体”用词都不同 -
Intl.DateTimeFormat和Intl.NumberFormat实例不可复用，每次切换语言必须新建，否则缓存行为会导致格式错乱 -
lang属性必须显式写在每个含文本的语义标签上（<p>、<h2>、<label>、<img alt>），浏览器不继承父级lang，只认当前元素自己的值 - 动态插入的 DOM（如 AJAX 弹窗、表格行）不会自动翻译，必须手动调用翻译函数，且要确保该函数作用域内能访问到当前语言包和
Intl实例
沙箱环境怎么用于国际化测试？
沙箱在这里不是指 <iframe sandbox> 防攻击，而是指构建一个与主站逻辑隔离、可独立配置语言偏好、模拟多端行为的测试环境。它解决的是“改了国际化代码，会不会意外影响已有功能”的问题。
使用场景：上线前验证 RTL 布局是否翻转正确；测试阿拉伯语下表单 placeholder 是否对齐；确认 localStorage 里存的语言偏好不会污染其他测试账号。
立即学习“前端免费学习笔记（深入）”；
- 用
http-server -p 8081 --cors启一个本地沙箱服务，避免file://协议下 fetch 被跨域拦截 - 在沙箱入口 HTML 中硬编码
document.documentElement.lang = 'ar'，并禁用自动检测逻辑，确保测试环境可控 - 用
localStorage.setItem('i18n_lang', 'ar')模拟用户手动切换，再刷新页面，验证是否真正生效而非仅靠 JS 变量 - 打开 Chrome DevTools → Application → Clear storage → 选中 “Cache storage” + “Local Storage”，一键重置沙箱状态，避免残留偏好干扰下一轮测试
工程化部署时怎么避免语言包污染？
语言包不是静态资源，它参与构建、加载、缓存、更新全流程。污染往往发生在构建阶段打包进 bundle，或运行时多个模块重复加载同一份 JSON 导致内存泄漏。
常见错误现象：构建后 en.json 出现在 vendor chunk 里，导致换语言必须全量 reload；fetch('./locales/en.json') 被 webpack 处理成绝对路径，上线后 404；热更新时新语言包加载成功，但旧 Intl 实例还在用老数据。
- 语言包路径统一为
./locales/${lang}.json，禁止内联或硬编码，让构建工具（如 Webpack 的import()动态导入）能按需分割 - 加载必须用
fetch()+try/catch+response.ok+ MIME 类型校验，不能依赖XMLHttpRequest或直接import—— 后者会让所有语言包打进初始包 - 语言包对象应做浅克隆（
{...langPack}）再传给翻译函数，防止某模块意外修改原始语言包（比如加了个临时调试字段） - 部署时在 Nginx 或 CDN 上为
/locales/*.json设置强缓存（Cache-Control: public, max-age=31536000），但文件名带 hash（如en.abc123.json），确保更新后立即生效
为什么 <iframe sandbox> 不适合做国际化隔离？
因为 sandbox 是安全沙箱，不是语言沙箱。它限制脚本执行、表单提交、弹窗等行为，但对 lang 属性、Intl API、DOM 文本替换毫无约束力——你完全可以在 sandbox iframe 里把 document.documentElement.lang 设成 ja，然后照样调用 Intl.NumberFormat('ja')，但它既不能帮你加载日语包，也不能防止主页面样式泄漏进来。
真正容易被忽略的点是：sandbox iframe 内部的 navigator.language 仍继承自顶层页面，无法独立设置；而 Accept-Language 请求头也由浏览器统一发送，iframe 无法伪造。这意味着你根本没法在 sandbox 里模拟“用户语言是阿拉伯语但设备系统语言是英文”的真实混合场景。
所以，别试图用 <iframe sandbox="allow-scripts"> 来跑多语言 demo——它解决不了任何国际化问题，反而增加调试复杂度。
