audio标签不支持真流媒体，但可通过HTTP Range请求实现“伪流媒体”边下边播；需服务器支持Accept-Ranges、正确Content-Type，且避免重定向与file://协议。
audio 标签本身不支持“流媒体”意义上的实时音频流（如 Icecast、Shoutcast 或 WebRTC 音频流），它只加载并播放 HTTP(S) 上的静态资源或渐进式下载文件。真·流媒体需用 MediaSource API 或 WebRTC，但绝大多数场景下用户实际要的是“可边下边播的远程音频”，这仍归为普通 audio 标签能处理的范围。
audio src 指向 MP3/OGG 网址就是最常用“伪流媒体”
只要服务器支持 HTTP Range 请求（现代 Web 服务器默认开启），audio 就能实现“加载即播、不用等全量”。这不是协议级流媒体，但对播客、背景音效、在线电台回放等场景完全够用。
- 确保音频 URL 是 HTTPS 或同源 HTTP（
http://localhost可行，file://不行） - 避免使用带重定向的短链（如 bit.ly），某些浏览器会丢掉 Range 头导致无法拖拽
- 服务端必须返回正确的
Content-Type：MP3 用audio/mpeg，OGG 用audio/ogg - 检查 Network 面板里音频请求的 Response Headers 是否含
Accept-Ranges: bytes，没有则拖拽进度条会失败
想播 Icecast/Shoutcast 电台？直接填流地址到 src 就行
像 https://stream.example.com:8000/stream 这类地址，只要它返回的是标准 MPEG-TS 或 raw MP3 流（且响应头含 Content-Type: audio/mpeg），audio 标签就能播——前提是该流支持 HTTP GET + Range（多数 Icecast 默认支持；Shoutcast v2+ 也支持，v1 不支持 Range，会导致无法暂停/拖拽）。
- 别加
autoplay，否则 iOS Safari 会拒绝（即使muted也不稳） - 必须加
controls，否则用户无法操作；流媒体没时长，进度条会显示“--:--” - 用
<source>多兜底没意义——流地址是唯一入口，不支持 fallback 切换 - 监听
onstalled和onerror事件比onended更实用，因为流不会“结束”
真需要低延迟实时音频？绕开 audio 标签，用 Web Audio API + fetch/Stream
若目标是语音聊天、实时伴奏同步、或毫秒级可控播放，audio 标签的缓冲和策略限制会让它不可靠。此时得用 fetch() 读取 ReadableStream，再喂给 AudioContext 解码播放。
立即学习“前端免费学习笔记（深入）”；
- 需要手动处理解码（MP3 需
ffmpeg.wasm或后端转 PCM）、时间戳对齐、缓冲区管理 -
MediaSource仅适用于 MSE 兼容格式（如 MP4 fragment、WebM），不支持裸 MP3 流 - WebRTC 的
RTCPeerConnection才是真正的实时双向音频流方案，但需信令服务器和 ICE 协商，复杂度高得多 - 简单测试可用：
const audio = new Audio("https://radio.example.com/stream"); audio.play().catch(e => console.warn("play blocked:", e));—— 这行通，就别上 Web Audio
真正卡住人的从来不是标签怎么写，而是服务器是否返回正确 Content-Type、是否支持 Range、以及移动端首次交互是否到位。流地址能播 ≠ 能拖拽 ≠ 能静音后恢复，每个环节都得单独验证。
