小程序实时音视频与直播能力

直播是当下转化率最高的内容形态之一。微信小程序内置了完善的实时音视频能力：live-player/live-pusher 组件让开发者可以快速搭建直播间，实时音视频（TRTC）服务则支持连麦、PK、多人互动等更复杂的场景。从「图文卖货」升级到「直播卖货」，是很多电商、教育、社交小程序的必经之路。本文从组件、链路、场景到合规，系统拆解小程序直播的实现路径。

一、小程序直播的两种实现路线

1.1 组件直连 vs 插件服务

1.2 组件使用的前提

live-pusher/live-player 组件不是默认开放的——需要在后台申请「实时播放音视频流」与「实时录制音视频流」权限，审核通过后才可使用。而且这两个组件对类目有严格要求（电商、教育、医疗等有直播需求的类目才容易通过）。

二、推拉流链路架构

2.1 经典直播链路

主播端
   ↓ live-pusher 采集编码推流（RTMP）
CDN / 流媒体服务
   ├── 转码、录制、截图
   ↓ 分发（RTMP/HLS/FLV）
观众端 live-player 拉流播放

<!-- 主播端：推流组件 -->
<live-pusher
  id="pusher"
  url="{{pushUrl}}"
  mode="RTC"                 <!-- RTC 实时 / SD 标清 / HD 高清 -->
  autopush="{{true}}"
  aspect="9:16"
  bindstatechange="onPusherStateChange"
  class="pusher" />

<!-- 观众端：拉流组件 -->
<live-player
  id="player"
  src="{{playUrl}}"
  mode="live"
  autoplay="{{true}}"
  bindstatechange="onPlayerStateChange"
  class="player" />

2.2 推拉流地址的生成

推流/播放地址通常由服务端从 CDN 或云直播服务生成，签名校验防盗播：

// 服务端生成推拉流地址（示意：腾讯云直播）
function genStreamUrl(streamId, isPusher) {
  const key = sign(streamId, EXPIRED_TS);   // 防盗链签名
  const protocol = isPusher ? 'rtmp' : 'https';
  const suffix = isPusher
    ? `?txSecret=${key}&txTime=${EXPIRED_TS}`
    : `?txSecret=${key}&txTime=${EXPIRED_TS}`;
  return `${protocol}://${DOMAIN}/live/${streamId}${suffix}`;
}

安全要点：推流地址必须签名+过期，否则任何人拿到地址都能冒充主播推流或免费拉流。

三、连麦与实时音视频

3.1 为什么组件不够

live-pusher/live-player 是「单向广播」模型，延迟在 1-3s 级别。连麦要求主播与嘉宾双向实时交互（延迟 < 500ms），必须引入 RTC 服务。微信内一般用腾讯云 TRTC 实现：

主播 TRTC 推流 → TRTC 房间
   ├── 连麦嘉宾：TRTC 双向互通（延迟 < 500ms）
   └── 观众：通过 CDN 旁路直播观看（延迟 1-3s）

3.2 TRTC 在小程序中的集成

// 引入 TRTC 小程序 SDK 进行连麦
import TRTC from './lib/trtc.js';

const trtc = new TRTC();
async function joinLiveRoom(roomId, userId) {
  await trtc.enterRoom({ roomId, userId });
  // 采集本地视频，推给房间内其他成员
  await trtc.startLocalPreview({ view: 'local-view' });
  // 订阅主播画面
  trtc.subscribeRemoteVideo({ userId: ANCHOR_ID, view: 'remote-view' });
}

3.3 连麦房的状态管理

连麦场景的核心是把「房间状态」做对：

实践要点：麦位、房间成员这类状态必须走服务端权威 + 广播，不能只靠客户端协商——否则连麦双方状态不一致会出各种奇怪 bug。

四、直播间搭建与商品组件

4.1 直播间页面结构

┌─────────────────────────┐
│  live-player（主播画面）  │  ← 全屏视频
├─────────────────────────┤
│  连麦嘉宾悬浮窗          │
├─────────────────────────┤
│ 互动：点赞/评论弹幕/礼物  │
├─────────────────────────┤
│  购物车 / 商品轮播       │  ← 直播带货
├─────────────────────────┤
│  主播资料 + 关注/分享     │
└─────────────────────────┘

4.2 直播带货的商品组件

直播场景下，商品以「挂载 + 讲解 + 一键购买」的形式存在：

Page({
  data: { currentSku: null, liveGoods: [] },
  onGoodsChange(e) {
    // 主播讲解某商品时，播放器下方同步切换商品卡片
    this.setData({ currentSku: e.detail.sku });
  },
  onBuyNow() {
    // 直接拉起支付，不走购物车
    wx.requestPayment({ ...this.data.currentSku.payParams });
  }
});

直播间转化逻辑与普通商城不同：强调「当下即买」，减少跳转层级，把商品卡片、支付按钮和直播画面放在同一屏。

五、稳定与性能

5.1 弱网与延迟策略

// 监听推拉流状态变化，断流自动恢复
function onPlayerStateChange(e) {
  const { code } = e.detail;
  // 2000 播放中 / 2001 加载中 / 2002 断流
  if (code === 2002) {
    setTimeout(() => this.player.replay(), 1000);
  }
}

5.2 费用与容量规划

直播成本大头是带宽：码率 × 在线人数 × 时长。千人同时观看 720p 直播，一天的带宽成本就可能上万。容量规划要点：峰值在线预估、CDN 带宽上限、按需转码档位（多清晰度覆盖不同网络）。

六、直播合规

直播是高敏感内容形态，微信对直播间的实时巡查 + 事后追溯都很严格，务必做好内容审核预案。

七、总结

小程序直播从「开箱即用的电商直播插件」到「自建推拉流的原生直播」再到「TRTC 连麦互动」，能力阶梯完整覆盖不同业务复杂度。选型建议：纯电商卖货用官方直播插件最快，自有流量与品牌诉求用原生组件 + CDN，教育与互动诉求必须上 TRTC。直播是「实时性 + 内容 + 转化」三合一的形态，技术方案要为业务峰值与合规留足余量。