iOS微信浏览器中autoplay无效，因WKWebView强制要求用户手势激活每个媒体元素：须在touchstart或WeixinJSBridgeReady回调中同步执行load()→play()→pause()预热，缺一不可。
iOS微信浏览器里autoplay属性基本无效，不是代码写错了，而是微信 WebView（基于 WKWebView）完全遵循 Safari 的媒体策略——必须由用户手势触发播放，且每个<audio>或<video>元素都要单独激活。
为什么WeixinJSBridgeReady监听后play()仍失败
常见错误是只监听WeixinJSBridgeReady就直接调play()，但此时元素还没加载、没被用户手势“激活”，Promise 会静默 reject，readyState卡在 0 或 1。
- 必须确保
video或audio已插入 DOM，且src已设置（不能靠preload="auto"代替显式load()） -
WeixinJSBridgeReady只是微信 JS SDK 初始化完成的信号，不等于媒体可播；它和touchstart一样，只是“可开始激活”的时机之一 - 若页面有多个媒体元素，只对第一个调
play()，其余仍会失败——每个都得单独走一遍load()→play()→pause()
iOS微信里video.play()报NotAllowedError怎么办
这不是异常抛出，而是 Promise 被 reject，且控制台可能无提示。关键不在“怎么 catch”，而在“怎么让 play() 有资格执行”。
- 必须在
touchstart、click或WeixinJSBridgeReady回调内同步调用，不能包在setTimeout、Promise.then或requestAnimationFrame里 - 调用前检查
video.readyState >= 2，否则play()大概率失败；可先video.load()再等loadeddata事件 - 务必加
playsinline和webkit-playsinline，缺一不可；否则即使播了也会强制全屏，iOS 微信下常直接中断 -
muted必须作为 HTML 属性存在（<video muted>），JS 后续赋值video.muted = true不算数
微信环境下audio元素预热的实操链路
音频比视频更敏感，iOS 微信甚至会拒绝未经过“用户手势+预热”的任何play()调用，哪怕已muted。
立即学习“前端免费学习笔记（深入）”；
- 收集所有待用
audio：const audios = document.querySelectorAll('audio[data-preload]') - 在
touchstart或WeixinJSBridgeReady中遍历执行：audio.load(); audio.play().catch(() => {}); audio.pause(); -
pause()不是为了暂停，是为了中断初始无声播放流、保留播放上下文，后续play()才不会被拒 - 如果要用声音，先保持
muted=true完成预热；用户点击按钮后，再audio.muted = false并立即play()（Safari 17+ 要求延迟 100ms 左右，否则可能中断）
最易被忽略的是：微信 iOS 环境下，autoplay属性本身毫无作用，连带muted+playsinline也救不了它；一切依赖 JS 的play()调用，而这个调用必须绑定到真实用户手势，并对每个媒体元素独立完成预热。
