html国际化硬性标准：lang属性必须根节点与局部元素双重设置且符合bcp 47规范；charset声明需与文件实际编码（utf-8无bom）、http响应头三者严格一致；i18n警告实为高危缺陷，直接影响字符显示、辅助技术可用性及字体回退。
HTML代码审查中，国际化（i18n）问题不是“可选优化”，而是直接影响字符显示、语言切换逻辑和辅助技术可用性的硬性标准。不检查 lang 属性、charset 声明或 HTTP Content-Type 一致性，轻则乱码、重则文本不可读，尤其在中文、阿拉伯语、日文等多字节语言场景下极易暴露。
lang 属性是否设置且层级合理
HTML 的 lang 属性是浏览器和屏幕阅读器识别语言的唯一可靠依据，但常见错误是只设在 根节点，而忽略局部语言切换。
- 必须为
添加lang，例如；若页面含英文引文、代码块或外语人名，需在对应元素上覆盖：如<blockquote lang="en"></blockquote> -
lang值应遵循 BCP 47 规范（如zh-Hans、ar-SA），避免写zh或chinese这类非标准值 - 不要依赖
meta http-equiv="Content-Language"—— 它已被废弃，现代浏览器完全忽略 - 若使用
dir="rtl"，必须与lang匹配（如lang="ar"+dir="rtl"），否则 CSS 逻辑属性（margin-inline-start）行为异常
charset 声明与文件编码是否真正一致
<meta charset="UTF-8"> 写在 开头 ≠ 文件实际以 UTF-8 编码保存。Nu Html Checker 会检测前 1024 字节内是否有有效 <meta charset>，但若文件带 BOM 或编码错位，仍会 fallback 到系统默认编码（Windows 下常为 GBK）。
-
<meta charset="UTF-8">必须位于最前面，前面不能有任何空白、注释或<script></script> - 用 VS Code 打开文件，右下角查看编码格式 —— 若显示 “UTF-8 with BOM”，请手动选择 “Save with Encoding → UTF-8（no BOM）”
- 检查服务器响应头：Chrome DevTools → Network → HTML 请求 → Headers → Response Headers → 确认
Content-Type: text/html; charset=UTF-8，而非GBK或缺失 - Apache 配置需加
AddDefaultCharset UTF-8；Nginx 需在server或location块中写charset utf-8;，**不能**用add_header Content-Type覆盖，会冲突
国际化相关警告是否被当作“只是警告”忽略
W3C Validator 和 Nu Html Checker 将 i18n 问题单独归类为“Internationalization warnings”，比如 Character encoding mismatch、Missing lang attribute、Unnormalized Unicode。它们虽标为 warning，但实际影响远超一般 warning。
-
Missing lang attribute：不仅影响 SEO 和语音朗读，还会导致 Chrome 对某些字体回退策略失效，中文可能渲染成方块 -
Character encoding mismatch：当 HTML 声明 UTF-8，但 CSS/JS 文件实际为 GBK 时，CSS 中的content: "你好";会直接变成乱码或解析失败 -
Unnormalized Unicode：同一汉字有多种 Unicode 表示（如全角/半角、组合字符），会影响字符串比较、搜索和表单验证，建议用 JavaScript 的String.prototype.normalize()统一处理 - Nu Html Checker 的
getMessageCategory()函数会把这类问题归入i18n类别，比 W3C 更细粒度 —— 它能区分出“HTTP header 与 meta 冲突”“BOM 导致 charset 检测失败”等具体原因
真正容易被忽略的，不是“有没有做国际化”，而是“所有资源（HTML/CSS/JS/JSON）是否用同一套 UTF-8（no BOM）编码保存，并由同一套 HTTP header 或 meta 控制”。一个 CSS 文件存为 ANSI，就能让整个页面的中文提示文字消失 —— 这种问题不会报 error，但用户一眼就看得到。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
