audio和video标签是声明式播放容器，非编辑工具；加src无画面/声音主因是浏览器禁止未静音autoplay，须加muted属性；controls为必要操作入口；路径错误或MIME类型配置不当（如.mp4返回text/plain）亦致失败。
audio 和 video 标签不是“编辑”工具，它们只是嵌入和控制播放的声明式容器——真要编辑音视频内容（如剪辑、转码、加字幕），得用 FFmpeg、Audacity 或专业非编软件。网页里能做的，是正确声明、兼容加载、可控播放。
为什么加了 src 却没声音/画面？
最常见原因是浏览器策略拦截了自动播放，尤其带声音的媒体。现代 Chrome、Firefox、Safari 默认禁止未静音的 autoplay，哪怕写了也会被忽略。
- 必须显式加
muted属性才能让autoplay生效：<video src="demo.mp4" autoplay muted controls></video> -
controls不是可选“装饰”，而是用户操作入口——没它，play()方法调用也可能失败（部分 iOS Safari 要求用户手势触发） - 路径写错或服务器未配置 MIME 类型（如
.mp4返回text/plain）会导致加载失败，控制台报ERR_CONTENT_DECODING_FAILED或 404
<source></source> 多格式写法和浏览器选择逻辑
浏览器不会按顺序试播，而是根据自身支持的 type 值匹配第一个能解码的 <source></source>。MP4（H.264 + AAC）兼容性最好，但仅靠它不够——Firefox 和旧版 Safari 对某些编码变体仍有问题。
- 推荐组合：
<source src="clip.mp4" type="video/mp4"></source>+<source src="clip.webm" type="video/webm"></source> -
type必须精确：写成video/mp4，不能写video/mpeg或漏掉video/前缀 - 不要依赖
<video></video>的src属性和内部<source></source>混用——优先用<source></source>，src会被忽略
poster 和 preload 实际影响什么？
poster 只在视频未播放前显示封面图，不影响加载行为；preload 才真正决定资源何时下载，但它受网络条件和用户设置制约，并非强制指令。
立即学习“前端免费学习笔记（深入）”；
-
preload="metadata"是较稳妥的选择：只拉取时长、尺寸、首帧等元信息，不下载主体数据 -
preload="auto"在移动设备上可能被浏览器无视（为省流量），且会触发预加载，增加首屏耗时 -
poster图片建议压缩至 100KB 以内，否则会拖慢首帧渲染，且需确保路径可访问（404 时显示空白）
真正容易被忽略的是错误降级处理：别只写“您的浏览器不支持”，要在 <audio></audio> 或 <video></video> 标签闭合前放一段纯文本提示 + 下载链接，比如：<a href="clip.mp3" download>点击下载音频</a>。这既服务老旧浏览器，也照顾了禁用 JS 的用户场景。
