小程序直播接入指南：live-pusher/live-player 与第三方 SDK 怎么选

很多企业的直播观众主要在微信里：培训学员从群里点进来，客户从公众号菜单进来，销售把直播间转发给客户。于是“直播能不能放进小程序”成了技术团队常被问到的问题。答案是能，但路径不止一条，每条路径的门槛、延迟和开发量差别很大。本文按“先看资质、再看组件、最后决定自研还是接 SDK”的顺序梳理。

小程序直播的第一道门槛不是代码，而是主体和类目。先确认能用哪些组件，再谈技术方案。

一、先弄清门槛：类目与权限

小程序里与直播直接相关的原生组件有两个：

• live-pusher：实时音视频录制，也就是在手机上采集摄像头和麦克风，把流推到服务端。
• live-player：实时音视频播放，拉取直播流在页面里播放。

这两个组件都不是所有小程序都能用。按微信官方文档，它们只对特定类目开放，例如社交类的直播、教育类的在线视频课程、医疗、金融、汽车、政府主体账号、IT 科技中的多方通信等（完整列表以官方文档为准）。流程是先在小程序后台补充或变更类目并通过审核，再到「开发」-「接口设置」里自助开通组件权限。

有两点经常被忽略：

1. 社交-直播类目审核更久。官方文档写明，选择社交类“直播”或“直播表演”类目后首次提交代码审核，需经当地互联网主管机关审核确认，预计 7 天左右。项目排期要把这段时间算进去。
2. 个人主体的限制更多。不少类目要求企业或机构主体，web-view 组件也明确不支持个人类型的小程序。

所以动手写代码前，先和运营、法务确认三件事：小程序的主体类型、已有类目、业务内容能否对应到可开通的类目。

二、四种接入路径对比

确认门槛后，可以从下面四条路径里选：

路径	观看延迟	类目门槛	开发量	适合场景
live-player 拉流（RTMP/FLV）	低，通常几秒以内	需要指定类目并开通权限	中	互动直播、带货、课堂答题
live-pusher + live-player（含 RTC 模式）	更低，适合双向	同上	高	手机开播、连麦、视频客服
video 组件播放 HLS（m3u8）	较高，常见数秒到十几秒	无直播类目要求	低	发布会、讲座、以观看为主
web-view 内嵌 H5 直播页	取决于 H5 播放器和协议	非个人主体，需配置业务域名	低（复用现有网页）	已有网页直播间，想快速覆盖小程序

几个说明：

• live-player 的 src 按官方文档目前只支持 flv 和 rtmp，所以服务端要能输出这两种格式之一。它的 mode 有 live 和 RTC 两种，RTC 模式时延更低。v2.9.1 起支持同层渲染，弹幕、商品卡片等可以直接用普通视图叠在画面上。
• video 组件本来用于点播，但同样可以播放 HLS 直播流。HLS 基于切片，延迟天然比 RTMP/FLV 高，切片时长和播放器缓冲越大延迟越高（协议差异可参考本站的直播延迟与协议选择）。
• web-view 打开的是网页，播放体验受 H5 播放器和系统 WebView 影响，自动播放、全屏、后台播放等行为要在真机上逐一验证。

三、自研组件方案要做哪些事

如果团队选择直接基于原生组件自研，小程序端的代码其实不多：放一个 live-player，绑定流地址，处理状态事件，用 wx.createLivePlayerContext 控制播放、暂停、静音和全屏。真正的工作量在小程序之外：

• 推流与源站：主播端用 OBS、导播台或 live-pusher 推 RTMP（OBS 参数可参考OBS 推流参数设置），服务端负责接收、鉴权和分发。
• 转码与多格式输出：同一路流至少要输出 FLV（给 live-player）和 HLS（给 video 组件、网页和兜底），通常还要多个清晰度。
• CDN 分发与防盗链：流地址加签名和过期时间，避免被盗播。
• 互动与业务：聊天、点赞、问卷、抽奖、商品、签到，这些都要自己写服务端和管理后台。
• 回放与数据：录制、转点播、观看时长和人数统计，以及与企业 CRM 或学习系统的对接。
• 异常处理：断流重连、弱网提示、切后台和来电时的暂停与恢复、不同机型的兼容。

团队有成熟的音视频后端，或者对数据和流程有很强的定制需求，自研是合理的；如果只是想把直播放进小程序，这些工作往往远超预期。

四、接入第三方直播 SDK 的取舍

市面上的云服务商和直播服务商大多提供小程序 SDK、插件或现成的观看页模板。它们帮你省掉的主要是第三节列出的服务端、转码、CDN、互动和后台工作，小程序端几行配置就能跑起来。

但要清楚几件事：

• 类目门槛不会消失。SDK 在小程序端通常仍基于 live-pusher、live-player 或 video 实现，组件权限针对的是你的小程序本身。
• 数据归属与导出。观看记录、用户留资、互动数据存在服务商那里，签约前确认能否通过接口实时导出，以及账号注销后的数据处理方式。
• 定制边界。界面和互动玩法能改到什么程度，是只能换皮肤，还是能拿到底层事件自己写页面。
• 多端一致性。同一场直播往往还要在网页、App、企业微信里看，SDK 是否覆盖这些端、体验是否一致。
• 计费方式。按流量、按并发、按时长还是按套餐，大型活动的峰值成本要提前估算。

更完整的平台评估维度可以参考企业直播平台选型。

五、怎么选：一个简单的决策顺序

1. 主体和类目：能开通 live-player/live-pusher 吗？不能的话，先用 video 播 HLS 或 web-view 方案上线，同时申请类目。
2. 延迟要求：需要实时问答、连麦、限时抢购，就必须走 live-player（必要时 RTC 模式）；以观看为主，HLS 足够。
3. 互动深度：互动和业务流程越复杂，SDK 或成熟平台的价值越大。
4. 团队人力和周期：没有音视频后端经验、上线时间紧，优先接入 SDK；长期大规模、强定制，再评估自研。
5. 数据与合规：涉及学员、患者、金融客户等敏感数据时，把数据存储位置、权限控制和审计要求写进需求。

六、上线前检查清单

• 类目审核和组件权限已开通，体验版、正式版都在真机上测过。
• 流地址带鉴权，过期时间合理；FLV 和 HLS 两路都能正常播放。
• 断网、切后台、来电、锁屏等场景下，播放能恢复或给出明确提示。
• 安卓、iOS、微信 PC 版和 Mac 版至少各测一台主流设备。
• 准备降级方案：live-player 异常时能切到 HLS，小程序异常时有网页观看地址。
• 正式开播前做一次全流程彩排，包括推流、互动、回放生成。

小程序直播的技术本身不复杂，难点在于门槛、延迟和业务功能之间的平衡。先把资质理顺，再按场景选路径，就能少走很多弯路。