必须加 controls 属性才能显示播放按钮和进度条；不加则 audio 标签仅为隐形加载器，无界面且无法交互，autoplay/loop 也无效；加 controls 后浏览器渲染原生控件，兼容性与无障碍最佳。
必须加 controls 属性才能显示播放按钮和进度条
不加 controls，<audio> 标签就只是个“隐形加载器”：音频可能静默加载，但用户完全看不到任何界面，也点不了播放、调不了音量、拖不了进度。哪怕写了 autoplay 或 loop，在大多数现代浏览器里也无效——它不会自动响，也不会弹出控件。
加了 controls，浏览器才渲染出原生控件条，包含播放/暂停按钮、音量滑块、进度条、时长显示。这是最轻量、最兼容、无障碍支持最好的方式。
-
controls是布尔属性，写成<audio controls>就行，不用赋值 - 不加该属性又想让用户操作？只能靠 JavaScript 调用
play()/pause()，但受用户交互策略限制（尤其移动端 Safari 基本拒绝无交互的play()） - 若用自定义 UI（比如用
<button>控制），反而要主动去掉controls，避免原生控件和自定义逻辑冲突
<source> 多格式写法容易因 type 错误导致控件不显示
控件能显示 ≠ 音频一定能播。如果所有 <source> 都加载失败，浏览器会退回到 fallback 文本，此时你看到的是一段文字，不是控件——看起来像“控件没出来”，其实是解码失败。
关键在 type 值必须是标准 MIME 类型，且顺序要按浏览器兼容性排：
立即学习“前端免费学习笔记（深入）”；
- MP3 放最前：
<source src="song.mp3" type="audio/mpeg">（不能写"mp3"） - OGG 次之：
<source src="song.ogg" type="audio/ogg"> - WAV 可选：
<source src="song.wav" type="audio/wav"> - 只提供一个格式（如只有 MP3）时，
<source>可省略，直接用src属性
移动端 Safari 对无 controls 的 <audio> 最敏感
桌面 Chrome/Firefox 在无 controls 时，有时还能响应 JS 的 play()（尤其用户已交互过）；但 iOS Safari 几乎一律拦截——哪怕 DOM 已 ready、play() 被调用、Promise 也返回了，就是没声音、没报错、也不触发 playing 事件。
这不是 bug，是策略：Apple 要求媒体播放必须由明确用户手势（click/tap）触发，且元素需有 controls 或至少可聚焦（tabindex）。
- 解决方案不是绕过，而是接受：要么加
controls，要么用带controls的<audio>+ CSS 隐藏样式（但保留可访问性） - 别试图用
visibility: hidden或display: none隐藏控件再 JS 播放——Safari 会直接拒绝 - 若真要隐藏 UI，可用
width: 1px; height: 1px; position: absolute; overflow: hidden;缩小控件，但仍保持其可交互性
设置 preload 影响控件初始响应速度
preload 不影响控件是否显示，但决定控件“能不能立刻点播”。设为 "none" 时，用户点播放按钮后，控件可能卡顿 1–2 秒才开始加载；设为 "metadata"（推荐），则只预加载时长、采样率等元数据，控件秒级响应，且不拉取全部音频流。
-
preload="auto"：浏览器自行决定，多数桌面端会预加载全部，浪费带宽 -
preload="metadata"：最平衡的选择，控件进度条可立即显示总时长，用户点击播放延迟最低 -
preload="none"：适合大文件或低优先级音频，但首次点击播放会有明显等待
真正容易被忽略的是：控件是否出现，不只是 HTML 写对不对的问题，而是 controls、source MIME 类型、preload 策略、以及移动端用户交互上下文这四者共同作用的结果。少一个环节，就可能在某个设备上“明明写了 controls 却没控件”。
