猎豹浏览器字幕乱码的根本原因是其旧版Chromium内核（≤v62）忽略BOM且依赖HTTP响应头，需确保.vtt文件为UTF-8无BOM、服务器返回Content-Type: text/vtt; charset=utf-8，并规范track标签写法。
猎豹浏览器（已停止维护）对 HTML5 字幕（<track></track> 标签加载的 .vtt 文件）显示乱码，根本原因不是它“不支持 HTML5”，而是它沿用旧版 Chromium 内核（≤ v62），且默认忽略或错误解析字幕文件的 HTTP 响应头与 BOM，导致 UTF-8 编码的中文被当 GBK 解析——这和你在 Chrome 里打开一个带 BOM 的 .vtt 文件却没设响应头，结果一模一样。
确认字幕文件本身是否为 UTF-8 无 BOM
很多字幕编辑器（如 Aegisub、Arctime）默认导出带 BOM 的 UTF-8，而猎豹会把 EF BB BF 当作内容开头，导致第一行偏移、后续全乱。这不是浏览器“有毒”，是它太老实——按字节读，不跳 BOM。
- 用命令快速验证：
xxd your-sub.vtt | head -n1
若输出含00000000: efbb bf，说明带 BOM - 用 VS Code 打开 → 右下角点击编码名 → 选
Save with Encoding→UTF-8（注意不是UTF-8 with BOM）→ 覆盖保存 - Notepad++：菜单栏
编码 → 转为 UTF-8 无 BOM 格式 → 另存为
强制服务器返回正确的 Content-Type 响应头
猎豹对字幕文件几乎完全依赖 HTTP 响应头，<meta charset="utf-8"> 对 .vtt 文件无效——那是给 HTML 看的，不是给 <track></track> 加载的外部文本资源看的。
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
-
.vtt文件必须由 Web 服务器返回Content-Type: text/vtt; charset=utf-8（不是text/plain，也不是缺charset） - 本地测试用
file://协议？猎豹直接失效——它不发 HTTP 请求，自然没响应头。必须起本地服务，例如：npx serve -s -p 8080
- Apache：在目录下加
.htaccess：AddType text/vtt .vtt<br>Header set Content-Type "text/vtt; charset=utf-8"
- Nginx：在 server 块中加：
types { text/vtt vtt; }<br>add_header Content-Type "text/vtt; charset=utf-8";
HTML 中 track 标签写法要“干净”
猎豹对 HTML 解析较严格，任何冗余属性或格式错误都可能让字幕加载逻辑中断或退化到自动编码探测。
立即学习“前端免费学习笔记（深入）”；
- 确保
<track></track>在<video></video>内部，且kind="subtitles"、srclang、label都存在（哪怕空值），例如：<video controls><br> <source src="movie.mp4" type="video/mp4"><br> <track kind="subtitles" label="中文" srclang="zh" src="sub.vtt" default><br></video>
- 不要写
charset="utf-8"属性（HTML 规范不支持该属性，猎豹会忽略） - 避免在
<track></track>标签前后插入 JS 动态插入逻辑——猎豹对 DOM 动态加载字幕支持极弱
真正卡住人的点，往往不是“怎么加 meta”，而是忘了 .vtt 是独立 HTTP 资源，它的编码命运完全由服务器响应头和文件字节流决定；而猎豹又恰好不兼容 BOM、不 fallback 到 <meta>、也不支持本地 file 协议下的 charset 推断——三重限制叠在一起，看起来像“乱码”，实则是整个加载链路里有一环没对齐。
