# 0001 — 浏览器直放音频流，不做服务端代理

状态：部分修订（RP 曲目信息由 0003 的宿主路由获取，音频仍直放；2026-10-24，原状态：已采纳 2026-10-23）

## 背景

电台插件要出声。两条路：在浏览器里用 `<audio>` 直接放远端流，或者在 dsh 主进程里起一个代理（转发音频、解析 ICY 元数据、解决跨域）。

约束与事实：7 条内置流全部 HTTPS、全部返回 `Access-Control-Allow-Origin: *`；dsh Web GUI 的主文档没有 CSP，音频不受 `media-src`/`connect-src` 限制；没有任何一条是 HLS。浏览器读不到 ICY 元数据（曲名/艺术家），只有服务端代理解析转发才能拿到。

## 决定

v1 用浏览器直放，不做代理，因此**不显示当前曲目**，只显示电台名（曲目信息由 0003 部分修订）。

## 后果

- 少一个进程、少一份要维护的转发逻辑，部署与分享的成本最低。
- 移动端和数据面都由浏览器自己处理；谁的设备打开界面，声音就在谁的设备上响。
- 放弃曲目名。若 v1.1 要做，必须引入代理（或找带元数据的第三方接口），届时再评估。
- 依赖流的 CORS 与 HTTPS 状况。新增电台时必须验证这两项，否则浏览器直放会失败。

## 备选与否决理由

- **主进程代理**：能拿到曲目名、能解决任意跨域，但要处理长连接、背压、端口与安全边界，v1 不值得。留到确实需要元数据时再做。
- **Web Audio 手动解码流**：复杂度更高，且不能绕开 CORS，收益为零。

## 照片与证据

`docs/network-probe.md`（可达性、content-type、CORS 实测）、`radio-plugin-feasibility.md` 第 4 节（CSP 与 Web Audio 先例）。