srclang属性写错本身不直接导致乱码，但会干扰多语言切换和fallback逻辑；真正引发乱码的是.vtt文件编码（须UTF-8无BOM）、HTTP响应头（Content-Type: text/vtt; charset=utf-8）及HTML中track标签写法三者不一致。
srclang 属性写错本身不会直接导致中文乱码，但会干扰浏览器对字幕语言和编码的处理逻辑，尤其在多语言切换、自动 fallback 或某些播放器行为中放大编码问题。真正引发乱码的，是 .vtt 文件本身的编码、<meta charset> 声明、HTTP 响应头三者之一或全部不一致。
为什么 srclang="zh-CN" 写成 srclang="cn" 会出问题
浏览器不靠 srclang 判断文件编码，但它会影响：
- 多语言字幕列表渲染时的默认激活逻辑（比如 Safari 可能跳过非标准值）
- 某些播放器 JS 库（如 video.js）内部语言匹配失败，转而尝试错误 fallback 编码读取内容
- 开发者误以为“语言设对了”，从而忽略检查真实 VTT 文件是否为 UTF-8 无 BOM
常见错误写法：srclang="ch"、srclang="Chinese"、srclang="zh"（缺少地区码，部分旧环境 fallback 不稳）
推荐写法：srclang="zh-CN"（简体中文）、srclang="zh-TW"（繁体）、srclang="ja"（日语无需地区码）
VTT 文件编码错误才是乱码主因
即使 srclang 完全正确，只要 .vtt 文件不是 UTF-8 无 BOM，中文照样显示为“涓枃”“锟斤拷”。
验证与修复步骤：
- 用 VS Code 打开 zh-CN.vtt，右下角查看当前编码（不能只看“UTF-8”，要确认是否带 BOM）
- 若显示 UTF-8 with BOM，执行“Save with Encoding” → 选 UTF-8（不含 BOM）
- Linux/macOS 快速验证：head -c 4 zh-CN.vtt | xxd，输出含 ef bb bf 就有 BOM，需清除
- Windows PowerShell 验证：Get-Content zh-CN.vtt -Encoding Byte | Select -First 3，若前三字节是 239 187 191，就是 BOM
HTML 页面自身编码声明必须同步生效
<meta charset="UTF-8"> 失效，VTT 即使编码正确也救不回来：
- 这个标签必须出现在 的最开头，前面不能有任何字符（包括空格、注释、BOM）
- 如果 HTML 文件本身存为 GBK，哪怕写了 charset="UTF-8"，浏览器仍按 GBK 解析整个文档，连 <track></track> 标签都可能解析错位
- 用 file:// 协议本地打开时，HTTP 响应头不存在，完全依赖 <meta>；走 http/https 时，服务器响应头 Content-Type: text/html; charset=utf-8 优先级高于 <meta>，但二者必须一致
检查方式：F12 → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers 查 Content-Type
动态切换字幕时最容易漏掉的编码链路
用 JS 切换 srclang 对应的 track.mode 时，别只改 mode：
- 确保每个 <track></track> 的 src 指向的是独立、编码正确的 VTT 文件（不要复用同一 URL + query 参数，缓存可能混淆）
- 不要用 innerHTML 或字符串拼接生成 VTT 内容再转 Blob 赋给 src —— <track></track> 不支持 Blob URL，静默失败
- 如果字幕内容由后端 API 动态返回，JS 获取后应创建新 <track kind="subtitles"></track> 元素，textContent 设为原始 VTT 字符串（确保 JS 引擎以 UTF-8 解析该脚本），再设 mode = "showing"
- Firefox 对 ::cue 样式中的中文支持较弱，若用 CSS 控制字幕字体，务必指定 font-family: "Microsoft YaHei", sans-serif; 等明确含中文的字体
