HTML页面国际化部署前必须验证的三件事：一是检查所有data-i18n元素是否覆盖placeholder/title/alt等属性并加对应后缀；二是确认每个含文本的语义化标签都显式设置了BCP 47格式lang属性；三是验证语言包JSON路径正确、Content-Type为application/json，避免fetch静默失败。
HTML页面国际化部署前必须验证的三件事
不验证就上线，语言包加载失败、lang属性错乱、动态节点漏翻译，用户看到的大概率是英文键名或空白——不是没做，是做了但没生效。
- 检查所有
data-i18n元素是否覆盖了placeholder、title、alt、aria-label等属性，只标data-i18n不够，必须加对应后缀如data-i18n-placeholder - 确认每个含文本的语义化标签（
<p>、<h2>、<footer>）都显式设置了lang属性，值为 BCP 47 格式（如zh-Hans、en-US），不能只改<html lang="zh"> - 验证语言包 JSON 文件路径是否正确、HTTP
Content-Type响应头为application/json，否则fetch('./locales/zh.json')会静默失败
静态托管平台（Netlify/Vercel/GitHub Pages）上的发布要点
这类平台不运行后端，所有国际化逻辑必须在前端完成，且资源路径极易出错。
- 语言包文件必须放在可公开访问的路径下（如
/locales/zh.json），不能放在/src或/dev目录——构建后这些目录通常不输出 - 确保
index.html中引用的 JS 文件（含翻译逻辑）使用相对路径或根路径（/js/i18n.js），避免因部署子路径（如my-site.netlify.app/blog/）导致脚本 404 - 如果用
localStorage记录用户语言偏好，上线后首次访问可能读到旧缓存，需在语言切换逻辑里加版本标识（如lang_v2）并清旧键 - 启用平台的自动 HTTPS 后，所有
fetch()请求必须走https://协议，本地开发用http://localhost测试没问题，但上线后混用协议会触发 CORS 阻断
服务端渲染（SSR）场景下的部署陷阱
Node.js 或 PHP 环境下做 SSR，容易把语言检测逻辑和前端割裂，导致首屏语言错乱或 SEO 内容与实际不符。
- 不要仅依赖
navigator.language决定服务端渲染语言——它不可靠，且 SSR 时该对象不存在；应由服务端解析请求头Accept-Language，再注入为全局变量或<html lang="xx">属性 - 若用 Express + EJS 渲染，确保模板中
<html lang="">和语言包数据同步传入，避免 HTML 的lang与 JS 加载的语言包不一致 - CDN 缓存会固化某语言版本，必须配置缓存键包含语言维度（如
Cache-Control: public, vary: Accept-Language），否则中文用户可能拿到英文缓存页 - 多语言 URL 路由（如
/zh/contact）需在服务端明确声明，否则静态托管无法识别，404 后 fallback 到index.html会导致路由错乱
上线后必须手动检查的三个真实场景
自动化测试很难覆盖这些点，必须人工点开看。
立即学习“前端免费学习笔记（深入）”；
- 打开浏览器开发者工具 → Application → Storage → LocalStorage，确认当前语言键（如
i18n_lang）值正确，且未残留过期值（如cn应为zh） - 右键页面任意文字 → “检查” → 查看对应 DOM 元素是否同时具备
data-i18n（或其变体）和正确的lang属性，两者缺一不可 - 在响应式模式下切换设备宽度，再切换语言——某些 CSS 媒体查询或 flex 布局在 RTL 语言（如
ar）下会因未设dir="rtl"或未用逻辑属性（margin-inline-start）而错位
lang 属性显式打点、动态节点插入后立即翻译——这三点不落实，部署再顺利，用户看到的也只是半成品。 
