lang属性必须为iana注册的bcp 47完整标签（如zh-cn），且仅置于标签上；须为内首个标签，严禁bom或空格；表单需显式声明accept-charset="utf-8"。
lang 属性是否为 IANA 注册值且位置正确
lang 属性写错或缺失，不是“翻译没出来”的小问题，而是直接导致屏幕阅读器语音库切换失败、CSS :lang(zh) 选择器失效、搜索引擎误判页面语种的硬伤。常见错误是写成 lang="cn" 或 lang="zh"，前者根本不在 IANA 语言子标签注册库中，后者缺少地区标识，部分辅助技术会降级处理。
-
lang必须出现在标签上，且值为完整 BCP 47 标签：简体中文用lang="zh-CN"，繁体中文用lang="zh-TW"或lang="zh-HK" - 禁止在子元素上重复声明
lang，除非内容语言确实切换（如引用英文段落），此时应写<p lang="en">...</p> - 检查构建产物（如 SSR 输出或静态生成 HTML）中的
，不能只看组件模板里写了就认为生效
charset 声明是否在 head 开头且无干扰字符
<meta charset="UTF-8"> 必须是 内第一个标签，否则浏览器前 1024 字节解析时可能按默认编码（如 Windows-1252）解码，导致中文、emoji 全部乱码。这不是偶发 bug，而是在旧 WebView、部分邮件客户端和离线缓存场景中稳定复现。
- 验证方式：用
curl -s URL | head -c 1024查看开头字节，确认<meta charset="UTF-8">紧跟后，前面无空格、BOM、注释或<script></script> - 禁止使用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 它是 XHTML 遗留写法，现代 HTML5 不推荐 - CI 中可加 shell 脚本校验：提取
内容，用grep -q "^<meta charset="检查首行匹配
表单 accept-charset 是否与页面 charset 一致
即使页面用了 UTF-8，<form> 提交时若未显式声明 accept-charset，某些 Safari 版本或旧 Android 浏览器仍会以 ASCII 或 ISO-8859-1 编码发送非 ASCII 字符，后端收到的就是乱码字节，且无法靠 header 补救。
- 所有
<form method=" post>必须带accept-charset="UTF-8"，不可依赖<meta charset>的隐式继承 - AJAX 提交时，
fetch需手动设置headers: { 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' } - 服务端不要做“自动猜测编码”——要么严格校验
Content-Type中的 charset，要么拒绝非 UTF-8 请求
HTMLHint + CI 如何落地国际化检查
人工肉眼核对 lang 和 charset 容易漏，尤其在多语言站点动态生成 HTML 时。工程化必须把规则固化进工具链，但默认 HTMLHint 不校验这些，需手动扩展。
- 在
.htmlhintrc中启用attr-value规则，并自定义正则：对lang属性强制匹配^(zh-CN|zh-TW|zh-HK|en-US|ja-JP|ko-KR)$ - 添加自定义 rule 检查
<meta charset>是否为第一个子节点（可用 AST 解析器，如parse5+htmlhint-plugin-ast） - CI 脚本示例：
npx htmlhint src/**/*.html --config .htmlhintrc || (echo "国际化检查失败"; exit 1)
<meta charset> 前面哪怕有一个看不见的 BOM 或空格，都会让整个页面的多字节字符解析崩塌**。这不是“上线后再修”的问题，而是构建阶段就必须卡死的红线。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
