正确写法是<audio src="music.mp3" controls></audio>，但需确保路径正确、使用HTTP服务器而非file://协议、配合用户交互调用play()并捕获异常，autoplay必须搭配muted才可能生效。
怎么用 <audio> 标签让网页播音频
直接写 <audio src="music.mp3" controls></audio> 就能播，但实际用起来常卡在“点了没反应”或“Chrome 里静音不自动播放”。关键不是标签会不会写，而是浏览器策略和资源路径是否真就位。
常见错误现象：Failed to load resource: the server responded with a status of 404 ()（路径错了）、DOMException: play() failed because the user hasn't interacted with the document（自动播放被拦了）。
- 必须提供至少一个
src，或用<source>子标签明确格式，否则 Safari 可能完全不加载 -
controls属性不能省——没有它，用户看不到播放按钮，也调不了音量 - 本地开发时双击 HTML 打开（
file://协议），Chrome 会禁掉<audio>的play()调用，得用本地服务器（如python3 -m http.server） - MP3 兼容性最好，但若要用
ogg或wav，得用多个<source>并按兼容性排序（Chrome 优先试 MP3，Safari 对 AAC 支持更稳）
为什么加了 autoplay 还不自动播
因为所有主流浏览器（Chrome、Firefox、Safari）都默认禁止无用户交互的自动播放，尤其带声音的。这不是 bug，是策略——防骚扰、省流量、保性能。
使用场景：轮播页背景音、信息亭（kiosk）模式、已获用户许可的 Web App。普通网站基本别指望靠 autoplay 播响。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
autoplay单独写没用，必须配合muted才可能生效（比如视频背景+静音音频） - 哪怕加了
muted，首次访问的页面仍可能被拦截，得等用户点过页面任意位置后再调play() - 想绕过？不行。监听
click后再audio.play()是唯一可靠路径，且要包在try/catch里——失败时不报错，但也不播
<audio> 的常用属性和它们的实际效果
属性不是越多越好，几个关键参数直接影响行为逻辑和用户体验。
-
preload="auto"：建议设，尤其音频文件小（none 则等用户点才拉流 -
loop：纯布尔值，写了就循环，不用loop="true"—— 写成字符串反而失效 -
volume不是 HTML 属性，得用 JS 控制：audio.volume = 0.7（范围 0–1） -
crossorigin：如果音频跨域（比如 CDN 上的 MP3），又想用 JS 读取音频数据（如做频谱分析），必须加crossorigin="anonymous"，否则报 CORS 错误
JS 控制音频时最容易漏掉的三件事
用 JS 操作 <audio> 很灵活，但也容易因细节掉坑里，尤其是状态判断和事件时机。
- 别在
load事件里立刻play()—— 此时音频可能还没解码完，应监听canplaythrough -
paused是只读属性，判断是否暂停用audio.paused === true，别写成audio.paused = true - 移动端 iOS Safari 对
play()极其敏感：必须由用户手势触发（touchstart、click），且不能包裹在异步回调里（比如setTimeout(() => audio.play(), 100)会失败）
最麻烦的其实是缓存和重用：同一个 <audio> 元素反复 src 赋值再 play()，有些安卓机型会卡住。稳妥做法是每次换音频就新建 new Audio(src) 实例。
