HTML5音视频状态管理应采用有限状态机（FSM），涵盖idle、loading、loaded、ready、playing、paused、ended、error八种状态，通过确定性原生事件驱动状态跃迁，并以“action→reducer→effect”模式实现不可变状态更新与副作用分离。
HTML5 多媒体组件（<audio> 和 <video>）本身提供基础播放控制，但缺乏统一、可复用、可预测的状态管理机制。实际项目中，需明确区分“加载中”“就绪”“播放中”“暂停”“错误”“结束”等状态，并支持同步 UI、响应用户操作、处理网络波动和跨设备行为差异。核心在于将原生事件与状态机结合，避免直接依赖 currentTime 或 paused 等易受时序干扰的属性做逻辑判断。
状态定义需覆盖生命周期全阶段
不能仅按“播放/暂停/停止”三分，应建模为有限状态机（FSM），至少包含：
– idle：元素已挂载但未触发任何加载；
– loading：src 设置后触发 loadstart，尚未进入就绪；
– loaded：元数据加载完成（loadedmetadata），可获取时长、尺寸；
– ready：首帧渲染就绪（canplay 或 canplaythrough，依策略选其一）；
– playing：正在播放（playing 事件，非仅靠 paused === false）；
– paused：主动暂停（pause 调用或 pause 事件）；
– ended：自然播完（ended），非用户中断；
– error：加载失败或解码异常（error + 检查 networkState / error.code）。
事件监听必须绑定到明确状态跃迁点
原生事件有延迟、可重入、可能丢失（如快速切换 src），因此状态更新只应在确定性事件回调中触发：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
loadstart→ 进入 loading -
loadedmetadata→ 进入 loaded -
canplay（或canplaythrough）→ 进入 ready -
playing→ 进入 playing（注意：此事件在调用play()后触发，比paused === false更可靠） -
pause→ 进入 paused -
ended→ 进入 ended -
error→ 进入 error，并检查media.error?.code分类错误类型（如 MEDIA_ERR_NETWORK / MEDIA_ERR_DECODE）
状态变更需封装为不可变动作与副作用分离
推荐采用“action → reducer → effect”模式：
立即学习“前端免费学习笔记（深入）”；
- 每个用户操作（如点击播放按钮）发出语义化 action（如
{ type: 'PLAY_REQUEST' }），而非直接调用play() - reducer 根据当前状态 + action 计算下一个状态（例如：在 idle 或 paused 下接收
PLAY_REQUEST，返回 loading 或 playing） - 副作用（如调用
play()、pause()、设置src）由独立 effect 模块执行，并监听对应状态跃迁触发（例如：状态变为 playing 时才真正调用play()，避免在 loading 阶段提前调用导致静音或失败）
UI 同步与外部控制需单向数据流保障一致性
组件 UI（播放按钮图标、进度条、加载指示器）应完全由当前状态驱动，禁止反向修改状态：
- 播放按钮显示逻辑：状态为 playing 显示“暂停”，paused/ready 显示“播放”，loading 显示旋转图标
- 进度条启用条件：仅当状态为 ready 或更高时允许拖动；loading 或 error 时禁用并置灰
- 外部控制（如快捷键、父组件指令）统一走 action 接口，不绕过状态机直接操作 DOM 元素
- 移动端自动播放策略差异（iOS Safari 需用户手势后首次 play 才生效）应在 effect 层适配：PLAY_REQUEST 在无手势上下文时降级为 ready，等待后续合法触发
