原生loop属性不可靠，仅控制末尾跳回开头，不处理静音不循环、Seek卡顿、解码中断等问题；iOS Safari等需muted+autoplay+playsinline且用户手势触发首次播放才生效。
原生 loop 属性在部分机型（尤其是 iOS Safari、微信内置浏览器、某些安卓 WebView）上会“看似生效实则中断”——不是不触发，而是播放到末尾后卡住、静音、或根本没触发 ended 事件。根本原因不是属性写错了，而是浏览器策略把「循环」和「能否播起来」强行绑定，一旦首次播放异常，后续全失效。
为什么 iOS 和微信里 loop 经常“播着播着就停了”
这不是 bug，是 Apple 和腾讯对自动播放链路的强管控：
-
loop只响应“正常播放完成”，网络抖动、解码卡顿、缓冲不足导致末尾未解码完，ended就不会触发，循环自然断掉 - iOS Safari 要求：必须同时有
muted+autoplay+playsinline，缺一不可；微信内嵌浏览器还额外检查x5-video-player-type是否为h5-page - 即使用户点过屏幕，若音频/视频未在用户手势回调中首次调用
play()，后续所有loop行为都可能被降权静音 - 服务端返回的音频响应头若缺失
Accept-Ranges: bytes，Safari 无法精准 seek 到结尾，ended事件延迟或丢失
用 ended 事件兜底时，必须加 readyState 判断
直接监听 ended 并 currentTime = 0; play() 在真机上容易报错或跳帧，因为播放器可能还没准备好重播：
- 只在
readyState >= HAVE_FUTURE_DATA时才执行重播，避免因缓冲不足导致play()失败 - 必须用
.catch()捕获拒绝，iOS 静音状态下play()会 Promise reject，不捕获就会静默失败 - 不要在
ended回调里重复设置loop = true，否则与原生loop冲突，可能造成双跳或卡死
const media = document.querySelector('video');
media.addEventListener('ended', () => {
if (media.readyState >= media.HAVE_FUTURE_DATA) {
media.currentTime = 0;
media.play().catch(e => console.warn('replay failed:', e));
}
});
移动端真机测试最容易忽略的三件事
模拟器测不出问题，真机一跑就断——这些细节不检查，90% 的兼容性问题都白调：
立即学习“前端免费学习笔记（深入）”；
- 首次
play()必须绑定在用户真实交互（click、touchstart）回调里，不能放在DOMContentLoaded或load事件中 - MP3 文件若含冗余 ID3 v2 标签或文件头损坏，iOS 解码器会在末尾崩溃，改用
.ogg（Vorbis）或 FFmpeg 重导出：ffmpeg -i in.mp3 -c:a libvorbis -q:a 4 out.ogg - 微信内嵌浏览器需确认是否启用了同层播放：
<video x5-video-player-type="h5-page">会禁用音频上下文，应改为x5-video-player-type="h5"或移除该属性
真正麻烦的从来不是怎么写 loop，而是你是否意识到：它只管“播完回开头”，不管“播没播顺”“回没回准”“卡没卡住”。所有机型兼容性问题，本质都是加载状态、解码时机、策略拦截这三者的叠加效应，漏查任意一环，循环就断在用户看不见的地方。
