lang属性声明页面语言以支持可访问性与seo，charset声明文档编码以防止乱码；二者功能独立，混用无效：lang错导致发音和索引错误，charset错导致字符显示异常。
lang 属性和 charset 完全不解决同一类问题：前者告诉浏览器“这段内容**用什么语言写**”，后者告诉浏览器“这段内容**用什么编码存**”。混用或互换，既不能防乱码，也不能提升可访问性。
lang 属性决定语音朗读、SEO 识别与翻译行为
屏幕阅读器（如 NVDA、VoiceOver）依赖 lang 切换发音规则；Google 和 Bing 用它判断页面主语言并匹配搜索意图；浏览器翻译插件也据此触发自动翻译逻辑。
-
lang必须写在标签上，例如，这是整页默认语言的唯一权威声明 - 局部语言切换可用
lang修饰具体元素，比如<p lang="ja">こんにちは</p>，此时屏幕阅读器会临时切日语发音 - 值必须是标准 BCP 47 格式：
en、zh-Hans、zh-Hant、fr-CA等，不能写chinese或cn - 写错或缺失
lang不会导致乱码，但会让视障用户听到错误音调，也会让 Google 把中文页当成英文页索引
charset 决定字节如何被解析成字符
<meta charset="UTF-8"> 是浏览器解码 HTML 文件字节流的“钥匙”。它不关心语言，只管“这串二进制该按什么规则转成文字”。
- 必须放在
最开头，且要在<title></title>之前 —— 浏览器一旦开始解析标题，就已按默认编码（通常是 ISO-8859-1）读取前几百字节，再改 charset 已来不及 - 值必须严格为
"UTF-8"（带短横、大写 U、T、F，数字 8），不能写成utf8、UTF8或utf-8，部分旧版 Safari 和微信 WebView 会忽略非标准写法 - 如果 HTML 文件实际保存为 GBK 编码，却声明
charset="UTF-8"，浏览器仍会强行按 UTF-8 解析，结果就是乱码 —— 声明必须与文件物理编码一致 -
charset对 SEO 影响间接但严重：乱码页面会被搜索引擎判定为“内容不可读”，直接降低索引优先级
lang 和 charset 错位时的真实报错现象
两者出错表现完全不同，排查时不能互相替代：
- 页面中文显示为 “æ们” 或 “й” —— 这是
charset错了，跟lang无关；检查文件保存编码 +<meta charset>声明是否匹配 - 屏幕阅读器把“你好”念成 /niː hɑʊ/（英语腔）—— 这是
lang="en"写错了，或根本没写；charset正确也救不了发音 - Google Search Console 显示“检测到页面语言与声明不符” —— 多半是
lang值太宽泛（如只写zh）或与页面主体内容明显冲突（如全文英文却写lang="zh-CN"） - 微信内打开页面标题为空、分享卡片无图 —— 这通常不是
lang或charset的锅，而是 Open Graph 标签缺失，但很多人第一反应去改这两个，白忙
最容易被忽略的一点：修改了 lang 或 charset 后，必须同时确认服务器响应头里没有冲突的 Content-Type（如 text/html; charset=GBK），否则 HTTP 头会覆盖 HTML 内的 meta 声明。本地开发时看不到这个问题，上线后突然乱码，往往就栽在这儿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
