ThinkPHP不能直接推流或播放，因其是HTTP框架，无长连接和音视频处理能力；RTMP/HLS等协议必须由SRS等流媒体服务器完成，ThinkPHP仅负责调度、鉴权与业务逻辑。
ThinkPHP直播带货系统不是“装个框架就能跑”的项目，核心难点在流媒体对接、实时交互与业务耦合——PHP本身不处理音视频流，必须靠外部服务（如SRS/ZLMediaKit）和阿里云/腾讯云直播SDK兜底；而ThinkPHP只负责房间管理、鉴权、礼物订单、商品挂载等业务逻辑。直接用ThinkPHP做推拉流会失败。
为什么不能用 thinkphp 直接推流或播放？
ThinkPHP是HTTP应用框架，运行在FPM或CLI模式下，不具备长连接、低延迟音视频处理能力。RTMP/HLS/FLV/WebRTC这些协议的推拉流必须由专用流媒体服务器完成，thinkphp 只能调度它、验证它、记录它。
- 试图在控制器里用
exec('ffmpeg -i ...')推流：不稳定、无错误反馈、无法监控状态、极易被超时中断 - 用
file_get_contents($hls_url)拉流：HLS是分片TS文件集合，PHP读取无法实现播放器所需的时间戳同步和缓冲控制 - 前端直接写死
rtmp://xxx/live/key：缺少 stream_key 动态生成、过期校验、权限绑定，主播可被冒用或盗播
stream_key 必须由 thinkphp 生成并绑定用户
真实场景中，每个主播进房前需获取唯一、有时效、带签名的 stream_key，否则无法防止未授权推流。这个逻辑必须落在ThinkPHP后端。
- 不要用固定字符串（如
'123456'），应组合：用户ID + 时间戳 + 随机盐 + 签名哈希，例如md5("uid_1024_".time()."_abc") - 存入数据库时，字段
stream_key要加索引，且关联user_id和room_id，便于后续查房主、禁用密钥 - 前端请求
/api/room/start接口返回{ "push_url": "rtmp://live.example.com/live/abc123", "stream_key": "abc123" }，而不是把完整URL暴露给JS - 流媒体服务器（如SRS）需配置
on_publish回调到ThinkPHP接口，校验该stream_key是否有效、是否过期、对应主播是否被封禁
礼物打赏和订单要在 thinkphp 层闭环，别甩给前端算
前端JS计算金币余额、扣减、发弹幕，全是可伪造的。所有关键状态变更必须经ThinkPHP后端校验并落库。
立即学习“PHP免费学习笔记（深入）”；
- 用户点击“送火箭”，前端只传
{ gift_id: 5, room_id: 1001, count: 1 }，不传金额、不传余额 - 后端
GiftService::send()方法内检查：user->balance >= $gift->price * $count、room->status === 'live'、gift->is_enabled === 1 - 扣款和订单创建必须在同一事务中完成：
Db::transaction()包裹user->decrement('balance')和OrderModel::create(...) - 成功后主动推送消息到WebSocket（Swoole或第三方IM），而非让前端轮询或自己发弹幕
别忽略 on_close 回调和离线状态清理
主播断网、OBS崩溃、手机切后台——这些都会导致流中断，但流媒体服务器未必立刻通知ThinkPHP。若不处理，数据库里 rooms.is_live = 1 会一直卡住，影响推荐、统计、连麦逻辑。
- SRS/ZLMediaKit 支持配置
on_closeHTTP回调，指向 ThinkPHP 的/api/stream/close - 该接口必须做幂等：用
stream_key查出room_id，再更新rooms.is_live = 0和streams.stop_at = now() - 加一层兜底：定时任务（如每5分钟）扫描
rooms.is_live = 1但最近10分钟无新弹幕/礼物的房间，自动标记为离线 - Redis里存的在线主播列表（
online:anchor:1024）也要同步DEL，否则粉丝页显示“正在直播”却黑屏
最易被跳过的其实是流媒体服务器与ThinkPHP之间的身份对齐——比如SRS回调携带的 app、stream 字段，要和你数据库里的 room.stream_key 严格一致，大小写、下划线、URL编码都得统一。一个空格没 trim 就会导致鉴权失败，直播间白屏没人知道为啥。
