default属性不可靠，因浏览器处理不统一且依赖用户无操作历史；应改用JavaScript结合navigator.languages或document.documentElement.lang主动匹配字幕轨道并设mode="showing"。
default 属性不可靠，别指望它让字幕“自动显示”
为什么default在多数场景下不生效
浏览器对 default 的处理逻辑不统一：Chrome 仅在用户从未手动切换过字幕时才启用它；Safari 可能直接忽略（尤其当多个 track 都写了 default）；一旦用户点过一次字幕开关，default 就永久失效，刷新页面也不恢复。
- 它不是“默认打开”，而是“首次加载时的兜底选项”，且依赖用户无操作历史
- 移动端 Safari（iOS 16.3 及更早）甚至完全不响应
default - 即使生效，也只影响
mode状态，不保证样式渲染或字体回退正确
真正可控的默认语言匹配方案
必须用 JavaScript 主动控制 textTracks，结合 navigator.languages 或 document.documentElement.lang 做匹配：
- 遍历
video.textTracks，找出srclang匹配当前系统首选语言（如navigator.languages[0]）的轨道 - 优先匹配完整 BCP 47 标签（如
zh-Hans）， fallback 到主语言码（如zh） - 找到后设
track.mode = "showing"，并确保其他轨道为"disabled" - 监听
load事件后再操作，避免textTracks还未就绪
示例关键逻辑：
立即学习“前端免费学习笔记（深入）”；
video.addEventListener('loadedmetadata', () => {
const userLang = navigator.languages?.[0] || navigator.language;
const targetTrack = Array.from(video.textTracks).find(t =>
t.kind === 'subtitles' &&
(t.srclang === userLang || t.srclang === userLang.split('-')[0])
);
if (targetTrack) {
targetTrack.mode = 'showing';
}
});
常见踩坑点：JS 控制前没检查 track 是否加载完成
video.textTracks 是一个动态集合，但它的初始化有延迟。在 DOMContentLoaded 或 video 元素插入 DOM 后立即读取，大概率拿到空数组或未绑定 src 的轨道。
- 错误时机：
document.querySelector('video').textTracks在readyState为0（HAVE_NOTHING）时为空 - 正确时机：监听
loadedmetadata（推荐）、或canplay；避免用onload（track不触发该事件） - 还要注意跨域限制：若
video或track.src是 CDN 资源，需服务端配置 CORS，否则textTracks可能被浏览器静默屏蔽
label 和 srclang 协同才能让 JS 匹配有意义
仅靠 srclang 匹配不够——用户可能切换系统语言为 en-US，但你只提供了 srclang="en" 的轨道，这时匹配成功；但如果还有一条 srclang="en-GB"，且 label 是 "English (UK)"，那 JS 就该优先选它。
-
srclang是机器可读的语言标识，用于基础过滤 -
label是人可读的区分依据，比如"Español (Latinoamérica)"vs"Español (España)"，JS 可据此做二次策略（如按地区偏好排序） - 不要把
label当成装饰：空字符串、重复值、纯技术名（如"vtt-zh-2024"）会让 JS 匹配逻辑失去上下文
最易被忽略的是：匹配逻辑必须考虑用户实际行为惯性。比如中文用户哪怕系统设为 en-US，也大概率想看中文字幕——这时候硬匹配 srclang 反而不如读取页面 lang 属性更合理。
