必须置于之前，否则非ASCII的lang值（如zh-CN）可能被错误解码为乱码，导致屏幕阅读器、:lang()选择器及Intl API失效。
lang 属性必须写在 之后？不，顺序反了会出事
浏览器解析 HTML 是流式的，<meta charset="UTF-8"> 必须出现在文档前 1024 字节内，且**必须早于任何含非 ASCII 字符的文本内容**——包括 中的 zh-CN 这几个字本身。如果 lang 属性写在 <meta charset> 前面，而页面又用了中文或日文等非 ASCII 语言值，Chrome 可能用默认编码（如 ISO-8859-1）解码该属性值，导致 lang 变成乱码（如 lang="й"），进而让屏幕阅读器、Intl API、甚至 CSS 的 :lang() 选择器失效。
正确顺序只有一条：把 <meta charset="UTF-8"> 放到 最开头，紧接着才是 。不要依赖“反正都是 UTF-8”就随便放；也不要指望后端模板引擎自动处理——很多 EJS、Jinja2 模板里 lang 是动态插入的，一不留神就插到了 charset 前面。
HTML 文件本身编码和 meta charset 不一致怎么办
常见错误是：文件以 GBK 保存，但写了 <meta charset="UTF-8">；或者文件是 UTF-8 BOM 编码，但声明为 UTF-8（BOM 会导致部分旧版 IE 解析异常）。这两种情况都会让浏览器渲染出错，尤其影响中文、日文等多字节字符。
- 用编辑器确认真实编码：VS Code 右下角显示编码格式，点击可切换；Sublime Text 查看 “File → Reopen with Encoding”
- 统一用 UTF-8 **无 BOM**：这是现代 Web 的事实标准，Node.js、Python、Nginx 默认都按此处理
- 服务端响应头优先级高于
<meta>：如果 HTTP 响应头里有Content-Type: text/html; charset=GBK，浏览器会忽略<meta charset>——务必检查curl -I your-page.html的响应头
RTL 语言（如阿拉伯语）布局翻转时，direction 和 dir 属性怎么选
direction: rtl 是 CSS 属性，作用于块级元素内部的文本流向和默认 text-align；而 dir="rtl" 是 HTML 属性，直接告诉浏览器该元素及其子元素的基线方向。两者不等价，混用容易冲突。
立即学习“前端免费学习笔记（深入）”；
推荐做法：
- 全局控制用
——这样所有继承自的元素都获得 RTL 基线，Intl格式化、表单光标移动、甚至 Flexbox 主轴方向都会自动适配 - 局部覆盖用
dir="ltr"（比如阿拉伯语页面里嵌一段英文代码），不用direction: ltr——因为后者只改文本流，不改 Unicode 双向算法上下文 - 避免同时写
dir="rtl"和style="direction: ltr"，浏览器行为未定义，Firefox 和 Chrome 处理逻辑不同
i18n 文本替换时，data-i18n 属性和 innerText 冲突怎么避
客户端 JS 国际化（如 i18next）常用 data-i18n 标记元素，再用脚本读取键名、查语言包、填入 innerText。但若原始 HTML 已含中文文本（如 <p data-i18n="welcome">欢迎</p>），JS 加载延迟时用户会先看到“欢迎”，再闪变为“Welcome”，即 FOUC（Flash of Untranslated Content）。
解决思路不是“等 JS 加载完再显示”，而是从源头切断干扰：
- 服务端输出空文本：
<p data-i18n="welcome"></p>，靠 JS 填充，不预留 fallback 文本 - 用
data-i18n-options控制行为，例如 i18next 支持{ "fallback": false }关闭降级 - 关键文案（如登录按钮）改用
<span data-i18n="login"></span>而非<button>登录</button>——避免按钮内联文本被搜索引擎抓取为“登录”而非目标语言
真正难的不是实现多语言，而是让 lang 值有效、让编码不打架、让 RTL 不翻车、让文本替换不闪烁——这些点不在框架文档首页，却决定国际化是否真的落地。
