HTML国际化（i18n）是支撑多语言的底层能力，需正确设置lang属性（如zh-CN）、UTF-8声明置于head最前、hreflang成组配对（含x-default）、表单验证与日期数字格式调用Intl API并显式传入locale，否则将导致布局错乱、RTL异常、乱码、SEO失效等问题。
HTML国际化（i18n）不是多语言的实现结果，而是让多语言成为可能的底层能力支撑。 没有正确的i18n基础，所谓“多语言网站”只是文本堆砌，容易崩布局、错乱RTL、乱码、SEO失效，甚至被搜索引擎判为重复内容。
lang属性写不对，浏览器就“看不懂”语言
HTML里lang不是摆设，它直接影响拼写检查、语音朗读、断行、字体回退和屏幕阅读器行为。错误写法比如： —— 缺少地区子标签，无法区分简体/繁体；<p lang="en-us"></p> —— 子标签大小写错误（应为en-US）；<span lang=""></span> —— 空值会覆盖父级语言，导致局部文本处理异常。
正确做法：
- 根元素用
或等完整BCP 47标签 - 混排内容显式声明，如
<span lang="ja">こんにちは</span> - 避免用
xml:lang替代lang（XHTML遗留，现代HTML5只认lang）
UTF-8声明漏掉或位置错，中文/阿拉伯文直接变
<meta charset="UTF-8">必须出现在最前面（在任何<title></title>或<script></script>之前），否则浏览器可能按默认编码（如ISO-8859-1）解析，导致中文显示为乱码，且后续JS读取DOM文本时已损坏。
立即学习“前端免费学习笔记（深入）”；
常见陷阱：
- 后端模板里把
<meta>插在<title></title>后面 - 使用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（过时写法，兼容性差） - HTTP响应头
Content-Type中指定了charset=GBK，强行覆盖HTML内声明
hreflang不配对，Google根本不知道哪个是英文版
多语言页面靠<link rel="alternate" hreflang="x">建立语义关联。漏掉hreflang="x-default"，或同一组页面中某个语言版本缺失对应hreflang声明，会导致搜索引擎无法识别语言变体，可能只索引一个版本，其余被降权。
必须成组出现，例如：
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/"> <link rel="alternate" hreflang="en-US" href="https://example.com/en/"> <link rel="alternate" hreflang="x-default" href="https://example.com/zh/">
注意：hreflang="x-default"不是“默认语言”，而是“未匹配到用户语言时的兜底页”，通常指向首选语言版本。
i18n做一半，表单验证和日期格式还在硬编码
很多人只翻了按钮和标题，却忘了input的placeholder、required提示、自定义校验错误信息，以及Intl.DateTimeFormat、Intl.NumberFormat这些API——它们依赖navigator.language或显式传入locale，但若页面lang和JS locale不一致，或没处理复数（如俄语3种）、文字方向（RTL输入框光标错位），用户一填表单就露馅。
典型疏漏点：
- 用
new Date().toLocaleDateString()却不传locale参数，默认用系统语言，非页面语言 - 表单校验用
if (value.length ，没走翻译函数 - 下拉选项（
<select></select>）文本来自前端静态数组，没随语言切换更新
真正难的不是加几个lang或换几份JSON，而是所有语言敏感点——从字符渲染、文本流方向、数字分隔符，到复数规则、日期排序逻辑、甚至CSS伪元素的content字符串——都得统一受控。漏掉任意一层，多语言就只是表面功夫。
