现代浏览器普遍拦截autoplay属性，仅当满足muted+autoplay+playsinline（iOS必需）且用户已交互时才生效；手动调用video.play()须在用户事件回调中同步执行，并检查readyState、捕获Promise错误。
autoplay 属性在现代浏览器中基本失效——不是你写错了，而是 Chrome、Firefox、Safari、Edge 全部主动拦截了它。唯一能绕过策略的组合是：muted + autoplay + playsinline（iOS 必须），且仍需用户已与页面发生过交互（哪怕只是点一下空白处）。
为什么写了 autoplay 却完全没反应
浏览器根本不会执行这个属性，除非满足策略条件。常见现象包括：视频卡在首帧、video.paused 始终为 true、控制台无报错但也没声音。这不是加载失败，是策略级静默拒绝。
-
autoplay仅对<video>和<audio>有效，写在<img>或自定义组件上毫无意义 - Chrome 66+ 要求必须同时带
muted，否则直接跳过播放逻辑 - iOS Safari 完全忽略
autoplay属性，无论是否muted，必须靠 JS 的play()调用，且该调用必须发生在用户事件回调内 - 如果
<video>初始是display: none或父容器visibility: hidden，即使属性全对，也会因未进入可播放状态而失败
play() 调用被拒绝的典型错误和修复点
手动调用 video.play() 是目前最可靠的方式，但它极易失败。关键不是“怎么调”，而是“什么时候调、怎么兜底”。
- 必须在用户真实交互事件（
click、touchstart）的回调函数中同步执行，不能包在setTimeout、Promise.then或异步加载完成钩子里 - 调用前建议检查
video.readyState >= 2（至少已加载元数据），否则可能抛出NotAllowedError或静默失败 -
play()返回 Promise，务必加.catch(e => console.warn("播放被拒", e))；常见错误信息是"The request is not allowed by the user agent" - iOS Safari 下，若没加
playsinline，play()可能成功但视频强制全屏弹出，体验断裂
移动端 iOS Safari 的硬性要求
iOS 是所有平台里限制最严的，漏掉任一条件就等于白写。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
-
playsinline是必需属性，不加就会全屏，且部分 iOS 版本下即使加了也需配合webkit-playsinline（兼容旧版） - 不能依赖首次加载时的
DOMContentLoaded或window.onload触发play()，必须等用户点击/触摸后才调用 - 不要在用户交互后立即
video.muted = false，Safari 17+ 会中断正在播放的静音视频；如需开声，应在播放开始后再延迟一小段时间（如setTimeout(() => video.muted = false, 100)），并捕获失败 - 微信内置 WebView（Android/iOS）行为不一致：Android 微信可能允许静音自动播，iOS 微信则几乎完全禁用，建议 UA 检测后降级为按钮触发
preload 和编码参数对“自动感”的实际影响
即使策略通过、play() 成功，用户仍可能感知到卡顿或延迟——问题常出在资源加载和解码环节。
-
preload="metadata"是自动播放场景的黄金配置：只拉取时长、宽高、关键帧位置，不下载画面数据，首帧就绪快且省流量 - 避免
preload="auto"，尤其视频 >2MB 时，弱网下可能卡住数秒甚至失败 - MP4 封装必须含
moov头在前（可用ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4修复），否则metadata加载会退化为下载整个头部 - H.264 编码推荐使用
Main Profile+level 3.1，关键帧间隔 ≤2s，能显著缩短解码启动时间
真正决定 autoplay 是否“生效”的，从来不是 HTML 属性本身，而是用户行为时机、设备类型、视频资源结构三者的交集。最容易被忽略的是 iOS 的 playsinline 和首次交互后的同步调用——这两个点一旦出错，其他所有优化都归零。
