Workerman不能直接播放消防广播，因其仅为PHP异步IO框架，无音频设备访问权限、不支持声卡驱动及系统播放器调用；正确架构应由其仅作指令分发，由终端本地播放预存音频。
Workerman 本身不直接处理音频广播或对接消防硬件，它只能作为消息中转服务——把“触发广播”的指令快速、可靠地推送到真正能发声的终端（如带音频模块的嵌入式设备、工控机、或已接入消防系统的网关）。想靠 Workerman 直接“播语音”是走不通的。
为什么不能用 Workerman 直接播放消防广播？
Workerman 是 PHP 的异步 IO 框架，核心能力是高并发 TCP/HTTP/WebSocket 连接管理。它没有音频设备访问权限，不支持 ALSA/PulseAudio，也无法调用系统 aplay 或 ffplay ——这些操作必须由有权限、有驱动、有声卡的终端执行。
常见误操作包括：
- 在
Worker进程里直接exec('aplay /alarm.mp3')：失败（无 TTY、无权限、子进程被回收） - 用
file_get_contents()读取音频文件再echo给浏览器：浏览器不会自动播放，且不满足消防强制离线可用要求 - 把音频 Base64 编码塞进 WebSocket 发给前端：依赖用户开着网页、没关标签页、没禁用自动播放——完全不可靠
正确架构：Workerman 只做「指令分发」
真实可行的链路是：管理后台点击「启动消防广播」→ Workerman 通过 WebSocket 或 TCP 瞬间通知所有已注册的物理终端 → 终端本地立即播放预存的 alarm.mp3。
关键设计点：
- 终端启动时连接到
Workerman的 WebSocket 服务（如ws://192.168.10.5:2346），并上报自身位置（如building_a_unit_3_floor_5）和设备 ID - 后台调用
sendToClient()或sendToGroup()推送结构化指令，例如：{"cmd":"fire_alert","level":"critical","audio":"alarm_urgent.mp3"} - 终端收到后不等待响应，立刻解码
audio字段（可为文件名或 CDN URL），用本地播放器触发硬件输出 -
Workerman不管播放是否成功，只保证指令送达；终端需自行心跳上报状态，失败时重试或告警
Workerman 服务端实操要点
避免踩坑的关键配置和写法：
- 必须用
Worker::setEventLoopClass()显式指定Swoole\EventLoop或Libevent，否则高并发下连接堆积 - 不要在
onMessage回调里做任何阻塞操作（如sleep()、file_put_contents()日志），日志统一走Worker::$logFile - 广播指令建议加简单校验：检查
cmd === 'fire_alert'且level在白名单内，防止恶意刷屏 - 生产环境务必启用
SSL（wss://），否则指令可能被中间人篡改；证书用ssl://+context参数传入 - 终端断线重连逻辑必须由客户端实现，
Workerman默认不保存离线消息——消防场景不允许“等你上线再播”
终端侧最简播放示例（Linux 工控机）
终端收到 {"cmd":"fire_alert","audio":"alarm.mp3"} 后，应执行类似逻辑：
#!/bin/bash
# /opt/fire-alert/player.sh
AUDIO_FILE="/opt/fire-audio/$1"
if [ -f "$AUDIO_FILE" ]; then
# 强制独占声卡，忽略其他音频干扰
aplay -D plughw:0,0 -q "$AUDIO_FILE" 2>/dev/null &
# 播放期间禁止休眠
systemctl inhibit --what=handle-lid-switch:suspend --who="fire-alert" --why="Emergency broadcast" --mode=block sh -c 'sleep 30'
fi
注意：plughw:0,0 需根据实际声卡调整（用 aplay -l 查），systemctl inhibit 防止系统在播放中途挂起——这点常被忽略，但消防场景下极其关键。
