playsinline属性仅对video有效，audio添加无效；ios safari中video自动播放需同时满足autoplay、muted、playsinline三条件，缺一不可，且须注意编码格式、cors及用户手势触发时机。
playsinline 属性只对 video 有效，audio 标签加了也没用
iOS Safari 和微信 WebView 等环境里，playsinline 是专为 video 设计的布尔属性，用来抑制全屏跳转。但 audio 本就不涉及“全屏”概念，浏览器压根不识别它的 playsinline。加了既不报错也不生效，纯属冗余。
如果你看到某段代码给 <audio></audio> 写了 playsinline，那大概率是复制粘贴时没删干净，或者误以为它和 video 行为一致。
-
audio在移动端自动播放，核心只看autoplay+muted（静音）是否同时存在 - 若
audio需要带声播放，必须由用户手势触发play()，且不能依赖muted = false后再调play()—— 这个组合在 iOS 上大概率被拒绝 - 安卓 Chrome 对
audio的 autoplay 限制更松，但 iOS 仍是铁律：不静音 ≠ 不允许自动播放，而是直接拦截
video 播放必须同时满足 autoplay、muted、playsinline 三者
少一个，iOS 就可能卡住第一帧、黑屏、或强制全屏。这不是概率问题，是 Safari 的硬性策略执行。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
autoplay单独存在 → 视频加载但不播放，控制台安静，行为不可见 -
autoplay muted齐全但缺playsinline→ 视频能播，但点击后立刻跳原生全屏，破坏页面布局 -
autoplay playsinline缺muted→ iOS 直接拒绝播放，play()调用会 reject，错误信息类似The request is not allowed by the user agent - 现代项目建议补上
webkit-playsinline，尤其要兼容 iOS 10–12 的场景（比如企业内网旧设备）
用户手势触发播放时，video.muted = false 必须紧挨着 play()
iOS Safari（特别是 17+）对“开声”非常敏感：如果 video.muted = false 和 video.play() 不在同一个事件回调里连续执行，它会中断当前播放流，甚至导致黑屏。
- ✅ 正确写法：
video.play().then(() => video.muted = false)或同步两行写在 click/touchstart 回调里 - ❌ 错误写法：
setTimeout(() => video.muted = false, 0)、放在 Promise.then 之外、或拆成两个独立事件监听 - 注意：即使视频已在静音播放，Safari 仍要求你先调一次
play()（哪怕它返回已 resolve），再改muted，否则无效 - 务必
.catch()捕获失败，因为部分用户禁用了媒体权限，此时play()会直接 reject
服务器与格式问题常被忽略，但会导致 autoplay 彻底失效
属性全对，代码也规范，但视频还是不播？大概率栽在这两个地方。
- 视频编码必须是 H.264 Baseline/Main Profile + AAC 音频，封装为 MP4；Safari 不认 WebM，Chrome 可能播但 iOS 一定挂
- MP4 文件需支持 HTTP Range 请求，否则 Safari 加载不到关键帧就卡住；检查响应头是否有
Accept-Ranges: bytes - 若视频托管在跨域 CDN，确保服务端配置了
Access-Control-Allow-Origin: *，否则canplay事件都触发不了 -
preload="metadata"比preload="auto"更稳妥，避免大文件预加载阻塞首屏，又不影响 autoplay 触发
playsinline 当成万能开关，加了就以为万事大吉。其实它只是拼图中的一块——muted 控制能否播，playsinline 控制在哪播，而用户手势、格式、CORS、编码，每一块掉链子都会让整个自动播放流程崩掉。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
