video.currentSrc 在 loadedmetadata 事件触发后才能可靠获取真实地址，此前可能为空或为初始值；若用多源声明，其值为浏览器最终选定的绝对URL。
video.currentSrc 什么时候能拿到真实地址
currentSrc 不是初始化就可用的，它依赖于浏览器完成资源选择（source selection）和加载准备（load metadata 阶段）。常见误区是 DOM 就绪后立刻读取，此时 currentSrc 往往为空或仍是占位符（如空字符串、about:blank 或初始 src 值，而非最终选中的源）。
必须等 loadedmetadata 事件触发后读取才可靠：
const video = document.querySelector('video');
video.addEventListener('loadedmetadata', () => {
console.log(video.currentSrc); // ✅ 此时为实际选中的 URL
});
- 如果用
src属性直接赋值，currentSrc通常与之相同（除非被重定向） - 如果用
<source></source>标签多格式声明，currentSrc是浏览器根据type、MIME 支持度、网络条件（如media属性匹配）最终选定的那个src - 动态切换
src后需重新监听loadedmetadata，不能复用旧事件
为什么 currentSrc 和你写的 src 不一样
差异主要来自三类情况：HTTP 重定向、<source></source> 多源协商、CDN 或播放器中间层注入。比如服务器返回 302 跳转到带签名的临时链接，currentSrc 就是跳转后的 URL；又或者你写了 <source src="vid.mp4" type="video/mp4"><source src="vid.webm" type="video/webm"></source></source>，而用户浏览器只支持 MP4，则 currentSrc 是 vid.mp4 的绝对路径（自动补全协议/域名）。
- 注意：若视频资源跨域且未配
crossorigin，部分浏览器可能拒绝暴露真实 URL，currentSrc返回空或原始相对路径 -
currentSrc返回的是解析后的绝对 URL，不是 HTML 中写的相对路径或 blob URL 字面量 - 对于
MediaSource（MSE）场景，currentSrc通常是blob:开头，但无法反查原始分片地址 —— 这是设计限制，不是 bug
currentSrc 在 autoplay 失败时还准吗
准，但时机更敏感。即使 autoplay 因策略被阻止（如静音未设、用户未交互），只要元数据加载完成，currentSrc 依然反映已选定的资源地址。问题在于：很多开发者把 currentSrc 获取逻辑绑在 play() 的 then 或 playing 事件上，而这些可能根本不会触发。
立即学习“前端免费学习笔记（深入）”；
- 正确做法仍是守
loadedmetadata，它不依赖播放是否成功 - 如果需要确认“这个地址真能播”，得结合
canplay或canplaythrough，但它们不改变currentSrc的值 - 移动端 iOS Safari 对自动播放限制极严，
currentSrc可能早早就有了，但play()会抛NotAllowedError—— 这和currentSrc无关，别混淆因果
想监控地址变化？别只靠 currentSrc
currentSrc 是只读属性，本身无变更事件。如果你动态切换 src 或替换 <source></source>，必须手动记录或重新监听生命周期事件。没有 currentSrcchange 这种原生事件。
- 简单方案：每次调
video.src = newUrl前先存旧值，赋值后再监听loadedmetadata更新缓存 - 复杂场景（如自适应码率 ABR）：播放器库（如 hls.js、shaka）通常提供自己的事件（如
hls.on(Hls.Events.FRAG_CHANGED, ...)），currentSrc在 MSE 下已无意义，应以播放器内部状态为准 - 注意：修改
<source></source>列表后需显式调video.load()，否则currentSrc不会更新
真正容易被忽略的是：当使用 preload="none" 时，loadedmetadata 可能延迟很久甚至不触发，currentSrc 就一直不可信 —— 这时候得结合 networkState 和 readyState 做兜底判断。
