audio标签必须置于body内才能正常播放，因其加载和交互权限依赖dom可见上下文；head中会导致play()失败、autoplay失效、readystate为0；位置应匹配用户交互节点，路径解析以audio所在dom位置为基准，type属性不可省略，fallback文本须写在标签体内。
audio 标签必须放在
虽然 HTML 规范允许 <audio></audio> 出现在文档任意位置（包括 ），但实际运行中，**放在 会导致多数浏览器无法触发播放、play() 报错或静音策略失效**。根本原因是：浏览器对媒体元素的加载和交互权限检查，依赖于其是否已挂载到 DOM 可见上下文中。
- 放在
时，audio元素虽被解析，但尚未进入渲染流，play()调用会立即拒绝（抛出DOMException: play() failed because the user didn't interact with the document first） -
autoplay+muted在中也常被忽略——不是语法错误，而是浏览器根本不启动加载流程 - 调试时可通过
document.querySelector('audio').readyState查看状态：0（HAVE_NOTHING）说明未开始加载，大概率是位置问题
为什么
放在 最上方（如紧贴 开始标签后）看似“尽早加载”，实则容易引发资源竞争和阻塞；放在最底部又可能错过用户首屏交互时机。关键不在“开头/结尾”，而在**是否与用户可感知的交互节点对齐**。
- 若需自动播放背景音乐，建议放在首个
<section></section>或主内容容器内部，确保它随首屏 DOM 一起就绪 - 若用于按钮点击触发的音效（如提交成功提示音），直接放在对应按钮附近更利于 JS 定位：
button.nextElementSibling比全局querySelector更稳定 - 避免嵌套在
<div style="display:none"> 或未渲染的 <code>aria-hidden="true"区域内——即使 DOM 存在，浏览器也可能跳过媒体加载<source></source>的路径解析以<audio></audio>所在位置为基准<source></source>标签的src是相对路径时，其解析起点不是 HTML 文件位置，而是<audio></audio>元素当前所在的 DOM 上下文——这在使用构建工具或前端路由时极易出错。- 例如：HTML 文件在
/pages/home.html，<audio></audio>在通过 JS 动态插入的组件里，该组件模板路径为/components/sound-card.html，那么<source src="beep.mp3"></source>会从/pages/beep.mp3加载，而非/components/beep.mp3 - 安全做法是统一用绝对路径：
<source src="/assets/audio/beep.mp3"></source>，或在 JS 中动态设置audio.src = new URL('./beep.mp3', import.meta.url).href（ESM 环境） -
type属性不能省略：缺少type="audio/mp3"时，Chrome 可能跳过该<source></source>，即使文件存在且可播放
不支持
<audio></audio>的老浏览器 fallback 文本必须写在标签体内fallback 内容（如“您的浏览器不支持音频播放”）只有写在
<audio></audio>开始与结束标签之间才生效；放在外部或用title属性替代完全无效。- 错误写法：
<p title="不支持"><audio></audio></p>→ 无任何提示 - 正确写法：
<audio controls>您的浏览器不支持 audio 标签。</audio> - 注意：该文本仅在浏览器彻底不识别
<audio></audio>标签时显示（如 IE8 及以下），现代浏览器即使加载失败也会显示控件并报错图标，不会展示 fallback 文本
<audio></audio>的 DOM 位置决定了它的生命周期、加载时机、路径解析逻辑和用户交互资格——它不是纯声明式标签，而是一个受上下文强约束的媒体实例。** - 例如：HTML 文件在
