webman实现高性能在线音乐播放平台的关键在于绕过http模型限制，通过workerman底层直接操作socket分块发送音频流，配合ffmpeg预处理、range请求支持及前端mediasource适配，而非依赖传统响应式文件输出。
Webman 本身不是专为音视频设计的框架，它不内置流式传输、分片控制或音频解码能力。想用它搭出“高性能在线音乐播放平台”，核心不在框架选型，而在于**如何绕过它的 HTTP 请求/响应模型限制，把音频真正“流”出去**。
直接用 file_get_contents() 或 readfile() 返回 MP3 文件？会阻塞 Worker、吃光内存、不支持拖拽和 Range 请求——这不是流媒体，是文件下载。
下面说清楚几个关键实操点。
Webman 中不能靠 Response::send() 做音频流
很多人试过在 Controller 里写：return response()->withHeader('Content-Type', 'audio/mpeg')->send(file_get_contents($path));。这看似能播，但问题极多：
- 整个文件读进内存再发，10MB 的 MP3 就占掉 10MB PHP 内存，Worker 无法复用
- 没有
Accept-Ranges和Content-Range响应头，浏览器无法拖动进度条 - 不支持并发断点续传，多个用户同时请求同一首歌，每个都重读一遍磁盘
-
send()是一次性输出，无法做 chunked transfer 或实时生成（比如动态混音）
必须用 Worker 直接操作 socket 发送音频流
Webman 底层基于 Workerman，真正的流式能力来自对 $connection 的直接写入。你需要绕过 HTTP 协议栈，自己构造 TCP 连接响应：
- 在
app/worker/下新建一个独立 Worker，监听专用端口（如8081），不走 HTTP Router - 用
$connection->send()分块发送音频数据，每次只读几 KB，边读边发 - 手动解析 HTTP 请求头里的
Range字段，定位到对应字节偏移再读取 - 响应头必须包含：
HTTP/1.1 206 Partial Content、Content-Type: audio/mpeg、Accept-Ranges: bytes、Content-Range: bytes 0-1023/1048576、Content-Length - 注意：不要用
Connection: close，保持连接用于后续 Range 请求
前端 audio 标签必须配合法服务器行为
<audio src="http://localhost:8081/song?id=123"></audio> 能播，但体验差。真正要支持拖拽、缓冲、暂停续播，前端必须配合后端的 Range 行为：
- 确保音频文件本身是“可 seek”的 MP3（ID3v2 在开头，不含 APE 标签；可用
ffmpeg -i in.mp3 -c copy -write_id3v1 1 out.mp3修复） - 避免用
src直接绑定 URL，改用MediaSource+fetch分片加载（适合自定义协议或加密场景） - 若用普通
<audio></audio>，务必确认服务端返回的Content-Length准确，否则 Safari 会拒绝拖动 - 测试时用 curl 检查响应头：
curl -I -H "Range: bytes=0-1023" http://localhost:8081/song?id=123，看是否返回206和正确Content-Range
FFmpeg 预处理比实时转码更可靠
别在 Worker 里调 shell_exec('ffmpeg -i ...') 实时转码——CPU 爆满、超时、并发一高就崩。正确做法是：
- 上传时触发异步任务（用
thinkphp-queue或amqp），用 FFmpeg 提前生成标准 MP3（CBR 128k，44.1kHz，ID3v2 清洁） - 存储路径按 ID 分片，如
/runtime/audio/123/123.mp3，避免单目录文件过多 - 如果要做多码率（如 64k/128k/320k），提前生成三份，由前端根据网络状况切换，而不是服务端动态转
- 注意：FFmpeg 默认生成的 MP3 可能含
VBRI头，某些浏览器 seek 不准，加参数-write_xing 1强制写 XING 头
